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:

Hi Alexey,

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]

Ouch.

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:

Alexey,

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

• 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.

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.

• If you've got feedback or ideas for Boomerang Calendar (or want to try it out), let me know!.
• If you're in need of a freelancer and want a full-stack generalist who loves product and has some experience with hackathons: that, also, is me.

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

• Pre-Hackathon Tutorials. Especially for a college hackathon, something like or git/python/html-css/javascript for beginners, and particular new interesting frameworks/tech for hackathon veterans are a great way to get the word out and build confidence. You're not going to teach anybody Ruby on Rails in sixty minutes, so consider the tutorials to be a chance to plant seeds and offer a technical head start. Newbies appreciate having at least some initial guidance and a rough path they can continue to take during the hackathon. Experienced hackers get a sense of what kinds of things might be fun to explore during the hackathon. I've seen PennApps put these together the week before and the Friday afternoon of the hackathon, both to solid attendance.
• 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.

Hack Breaks

• 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).

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.

• 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.

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.

• 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).

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.

HackNY Fall 2012:

Michigan's Learn To Hack:

Logistics Hacks

• 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).

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.

• 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%.

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.

• Room for Improvement: Drinks Vendors.

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.

Demo Hacks

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:

• Demoing mobile apps

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.

• Preparing teams for their demo:

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.

• Demo Order Use things like HackerLeague (or just Google Forms) to organize the demo submissions and order.

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..

• 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.

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.

That sucks.

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.

Updates:

• 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.

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

• 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.

Labs README

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.

A quick public service announcement about MongoDB, for those of us new to NoSQL land:

By default, mongo will not let you know if a query that you ran failed miserably.

On the bright side, you on longer need to wait for mongo to unblock for updates or inserts, which makes production code run quicker.

Unfortunately, this also means you're going to spend more time tracking down bugs that would have been caught by IntegrityErrors (or the equivalent) in good old SQLite.

But I LIKE knowing about integrity errors. Me too, especially when testing locally.

Here's the fix: set safe=True in your Mongo connection object. In django non-rel, this means setting

DATABASES = {
  'default': {
    ...
    'OPTIONS': {
      'safe': True
    },
  },
}

in settings.py.

Good luck!

For the past few months I've been using Sidecar whenever I'm in SF. The service is a sort of Uber meets Gypsy cabs, allowing ordering on-demand everyday drivers, who will give you a ride across town at a price comparable or slightly cheaper than a Taxi.

A post about the service's legal standing is probably worthwhile but not for me to write. Should you use Sidecar? Yes, if you're looking for Uber-like service at Taxi-like prices and aren't made uncomfortable by just how sketchy the whole thing feels. The service is invite-only for now, but if you're in SF: here, have an invite (and 10 bucks).

The Reputation of ETAs

I am fascinated by digital reputation systems, having focused on them in my senior thesis.

Wait times matter. In the taxi world (where a few of the drivers I've met come from), operators keep track of passengers who repeatedly order cabs and then don't show up. After a couple of no-shows, a phone number or address gets the equivalent of Hellbanned - if they order a cab again, the operator will tell them the cab is on its way and then just not send anybody, leaving the passenger stranded. It's a cruel sort of system, but in lieu of a real-world consumer reputation system, it's the only way I can think of for a cab company to punish poor behavior, like a waiter spitting in food.

In Sidecar's reputation system, a passenger is rated 1-5 by drivers, but only once a ride is complete. A cancelled ride, then, is not globally stored within Sidecar's system, at least in a way visible to drivers. The driver that was telling me this story compensates by "just remembering people" once they have skipped out on a ride or two. In one case, he accepted a ride that claimed to be fifteen minutes away and proceeded to "walk into a deli, order a sandwich and some chips, make small-talk with the owner, and then eventually come pick the guy up."

The Solution

In Sidecar's case, I propose a reasonably straightforward solution: give passengers a reasonable window within which to cancel (90 seconds? 120?). If they don't cancel, add the notification to their reputation system (late-cancelled 6% of Sidecars). Let both parties know that this is criteria that drivers will see. You'll get fewer cancellation and fewer drivers having to "remember people" and punish them passive-aggressively.

Whenever a friend visits our HQ, I proudly show off my combination sit/stand desk. Often, that results in an email asking where one buys such a thing. One buys such a thing on amazon.

Wait, why a standing desk?

Sitting is killing you, apparently. I don't get as much exercise as I'd like now that I'm out of college, and at the least, standing for part of the day means I'm getting at least some exercise.

The options I explored

• There have been a few "Standing desk for cheap" blog posts on Hacker News recently, but none of those allow me to easily move from sitting to standing. I could sit on a high stool, certainly, but that didn't seem particularly ergonomic. So, I went for the cheapest effective adjustable setup I could find.
• My stand is reasonably cheap ($370) and slides from sitting to standing via a gentle pull of the monitor up or down. I couldn't find anything else that offered a similar service for under $600 or so.
• There are several models of the Ergotron available, depending on # and size of monitors you'd like, and whether you need a laptop at standing height as well. One 30'' was plenty for me, and came in at $370. Adding a second screen or a monitor would have bumped the price, but not by much.

How I like it.

• Installation was reasonably straightforward (took about a half an hour to build the thing). The mount expects the back of your monitor to have certain dimensions in the mounting hinge. Check before buying.
• Overally, I'm pretty happy with the purchase, given the price point.
• I'd be lying if I say that I've gotten myself standing most of the time. I'm writing this sitting down. But I definitely stand more than I would otherwise; it really depends on my energy on a daily basis. I've definitely still got room for improvement.

So, that's my setup. Feel free to get one for yourself.

PS: A friend of mine is running a kickstarter for a portable standing desk, for $150. Seems pretty useful if you want to travel and have a standing work setup.

My weekend hack is a Markov Chain baby name generator. @MarkovBaby will come up with a new baby name once an hour and tweets it out.

The result: Follow @markovbaby on Twitter.

What is a Markov Chain?

Read the wikipedia entry for a more thorough introduction, but in our case, a Markov Chain is a simple random process to generate text that looks sort of like other text.

For example: as we're generating baby names, say we start with the letter "C". What should be our next letter? Well, what kind of letters usually come after a "C" in names? Let's look through our list of existing names and see what usually comes next.

Great. Let's pick the next character at random from within this list, weighing each possibility by how often it appears. If we get 'end of word', we're done.

But let's say we've picked 'h'. Great - so far the name starts with a 'ch' - let's look for the next character: what tends to follow an 'h' in our existing names? And so on.

Results

The result are a rather eclectic set of names. Some are silly and non-sensical (C, Ieahaholijayson), while others seem pretty reasonable (Marin, Gacon). A lot of them sound like they belong in Middle Earth (Miaviria), to Weseteros (Josth, Mindron). Occasionaly it'll accidentally recreate a real name. Those are my favorite.

@MarkovBaby may be suitable for an expecting couple with just the appropriate amount of eccentricity and love of statistics.

The code

Is available on my github. Hopefully nothing too complicated; random.choice and collections.defaultdict proved rather helpful. I hadn't touched Markov Chains since proving things about them in Randomized Algorithms class, so it was good to know that with a bit of clever python you could write one in a few dozen lines. For reference, mine was an 'order-1' (IE, only look at one previous character) chain.

See also, a discussion on Markov Chain implementations in Programming Pearls.

Possible extensions

• Favorite or RT your favorite baby names, and I'll put up a leaderboard for favorite ones.
• Apply the same techniques (and same code) to startup names, using crunchbase: Markov 2.0.

If you've got a twitter bot missing in your life, follow @markovbaby on Twitter. Or follow me. That would be cool too.

I worked on non-technical hiring over this past week.

Some Lessons Learned

• There are a lot of people on craigslist. We got over 160 applicants for our post.
• Some are pretty darn good 40 or so were potentially interesting, and I ended up with about 5 candidates I was very happy with at the end of the process.
• Applications should be hard Our application form included several paragraph answers, forcing candidates to think and allowing me to evaluate their writing style. This proved very helpful.
• Templates are your friend That means 120 rejections. For technical hires, I do my absolute best to give feedback, especially for younger candidates, on what to work on. With this volume of candidates, include many just spray-and-praying their resume, I had to go with a template for most hires.
• Duplicate test assignments for potentially worthwhile candidates, I came up with a realistic task that would take about an hour and asked them to send me their results before considering an interview. I learned a ton from seeing more than 20 people complete the same assignment, including what I was looking for in an ideal candidate. Things like how well they communicate with me, whether they ask questions (and whether these are the right questions or just things they could have googled), whether they are comfortable making assumptions and moving forward if I am unavailable, etc.
• Education is a far stronger signal for non-technical hires With technical resumes, I may glance over where they got their undergrad but focus much more on experience and publicly available code. For non-technical hires, places they've worked/things they've done before aren't nearly as indicative of quality (at least to me) as for technical roles. The highest signals of quality (quality measured by 'I am interested in hiring this candidate') ended up being things like caliber of undergraduate education and the candidate's ability to answer the initial questions well. Being used to the "it doesn't matter where you went to school, what we care about is what you've done" school of thought for technical hiring, this surprised me.

Things I'd change next time around

• Send almost all of the candidates through the challenge first. I met with a lot of candidates in person before sending them the challenge; in retrospect, in a buyer's market, this should have been reversed.
• Filter for 'having read the requirements' by including a sentence like "Please ensure to include the capital of Denmark somewhere in your application." This would have filtered a ton of spray-and-prayers.

I may be a bit late to the Jekyll party, but with Posterous being acquired by twitter a few months ago, I figured why not try it out. Two weekends later I've migrated enough that I'm comfortable shipping, though I imagine a bunch of silly bugs will remain. Please email me with any issues you find, and I'll get to them when I can.

In the meantime...

Moving from Posterous to Jekyll: What you need to know.

• Jekyll is a static site generator created by GitHub for GitHub Pages. It is rather extensible, so people have built things like Jekyll-Bootstrap and Octopress on top of it. I sort of half-used the former (adapted a theme) and didn't know about the latter until it was too late. Maybe/probably use Octopress if you go this route.
• Migrating from Posterous kinda-sorta works. The migrator that includes images/permalinks is on github here. Some ruby required. Here's my hacky version, with a couple of updates.
• Comments I haven't moved mine yet but a guide to move posterous comments to disqus is available. The decision to have comments (even moderated ones) is not one I've made yet. We'll see.
• RSS Here's the jekyll+feedburner guide
• Developing Locally I used guard to auto re-generate pages as I was iterating on the CSS hackery. Pretty useful, especially if you're already reasonably comfortable with guard.
• Hosting GitHub Pages will host for you at yourusername.github.com + let you host on your domain if you add a CNAME to your distribution. I'm about to try it. Fingers crossed. Also, I don't know how much I trust GitHub to be so generous in the long run, but my next migration is going to be far less painful - "it's just static content". Note: I was worried about where to stick draft posts, since the repo needs to be public, and my solution was to have both a public and a private repository, so releasing is "git commit -a && git push public master."
• Markdown I admit I'm not too experienced with Markdown. Here's my cheatsheet.

I tried Exec for the first time today.   

TL;DR - don't half-ass the task description/understanding what you actually need.

Motivation:
I had found a blog post with a ton of discussion online that had some great comments showing a deep understanding of the material.  "These people are awesome," I thought. "Let's see who among them we could hire!".

Huzzah, finally a chance to try TaskRabbit andExec.

My description:

I'm looking for contact info for a few (about 10-15) posters from a couple of blog posts (links below)

Result: I'd like an excel spreadsheet that looks like this, for every commenter that seems to be well-received.  You may need to start with the Username and google for all of their other info.

Spreadsheet format:
Username | What They Said (+Link) | Contact Info (email?) | Github | Personal Website | Current Occupation

After posting on TaskRabbit and getting no bites for an hour or so, I went to Exec instead. Within 10 minutes, I got a call from my new Exec and Sarah (name changed) got started.

Correspondance with the Exec (edited for brevity)
30 minutes in

Sarah: Would you prefer not to post a 'conversation' between the user and other users who are commenting back to the main user?

Or shall I post some of those as well?

Me: A link to the comment and a snippet of their comment (about a sentence) would be great!  I'll follow the link if I'm looking for more context.

55 minutes in

Sarah: Excuse me, what does 'github' mean, please? Also may I add a column showing what they have posted...as in those links?  I'm also having trouble getting their personal info from the first URL you gave me.  

Me: 

- I'd take their username and google around to see if you can find them somewhere else online.  No worries if you can't find contact info for all of them, but most should have a github/blog/etc which will have an email address.  
- Github is github.com, a website that many engineers use to display code they have worked on. It's reasonable to expect most everybody who made a comment is going to have a github account as well, probably with the same username as the comment

2 hours in

Sarah: I have 8...still working...wanted to give you an update!

2:15 in

Sarah:  OK...here it is...10 total now.

Me:  Looks good!  [review briskly in the middle of other work] The one detail I'd love to have, that I wasn't clear about in retrospect, would be the name of their current employer (in position, rather than the title, I'm also interested in who they are working for).

Sarah:  Most of them don't say who they are working for, but I'll add that tab and go back and look at them again.,..if this goes longer than 3 hours.  is that OK with you? Or do you want me to stop at 3 hours? We are at 2hr.25 min right now.

Me: Sure, stop at 3 hours.

Aftermath 

Later that night, I pulled open the spreadsheet.  The people Sarah had chosen were not necessarily the ones I felt had made particularly insightful comments. Sarah didn't have any domain expertise; as a result, I discarded a few of the 11 almost immediately and started to read through on the rest.

My workflow with the Spreadsheet was not optimal - I ended up bouncing back and forth between the links provided to figure out if this person was worth contacting. I was duplicating a lot of the work that I had hoped to have Exec handle for me, and am not sure how much time I saved (I ended up googling about half of their usernames anyway to find more things about them).

I did end up emailing a few people that were worthwhile, but I'm not convinced that between specifying the task, managing Sarah and then looking through the spreadsheet I saved myself all that much time. Sarah was very friendly and responsive, but ultimately I tried to outsource judgment that required domain expertise, and was only marginally successful.

I showed up at stumbled upon was tricked into an Iron Blogger SF meetup on Saturday, and was not allowed to have any of the beer until I found out what the meetup was about and convinced to partake.

Iron Blogger is simple.  

Write a blog post once a week.  If (and when) you don't: you owe $5.  When there's enough money in the digital pot to afford a sufficient quantity of beer, a meetup is convened.

Once a week is tough. My most interesting and well-read blog posts have typically consisted of lengthy write-ups or niche guides for hackathon organizers or Bay Area tech interns. It's not really blogging, per se - the writing model I aspire to most is Joel Spolsky, a sort of Joel without the wisdom, experience, or wit.

So this is very different, and I can't say I'm particularly comfortable with it. These coming posts won't all be what I consider ready-to-ship, or particularly well-researched or thorough.  I don't expect them to be nearly as well-read. Hopefully, they'll force me into improving my writing.

It's that or $5 a week.

"Well, I wasn't really going to intern at X (say, Zynga, or Morgan Stanley) but they offered more than anybody else."

Don't do that.

It's easy to focus on the financial aspect of an offer, especially if it's the first time you've had a chance to make anywhere near this much. It feels kind of surreal.

It's not that money isn't a valuable proxy for how valuable the company perceives you to be. If you get an offer of "housing + we give you options in the company," that's a good sign that you are talking to Whartonite Seeks Code Monkey-esque enterpreneurs and if you have anything remotely more interesting available you should go do that instead.

But the point of an internship is not to maximize your profits - it's to learn what kind of work or industry you want to be in once you graduate, to try things out and live in cool places, and (more immediately) learn about how real-world software engineering works.

When you go out into the real world with six figures of college loans, sure: try to negotiate up your offers, consider the difference between $80k and $100k a year.  This will make a substantial difference in how soon you will be free from debt.  But when you are deciding where to spend your summer, the difference of a few $k is a small price to pay for learning about a potential industry or position or company that you are interested in as a career.

PS.  In case you're wondering, here's an approximate price that companies are paying these days for technical interns. I imagine this'll be out of date reasonably soon, but here it goes*:

• ~$10k/month - crazy financial hedge-funds where they have you do algorithms trading or something along those lines. Expect +$2k/month for every greek letter in their name.
• ~$7.5k/month - Google. I think Google still makes a point of paying 10-20% more than anybody else, but I haven't checked recently. Edit: Palantir appears to be in this bracket as well.
• ~$6-7k/month - Facebook, Dropbox, Twitter, Microsoft, Apple, etc - top-tier tech companies.  
• ~$4-6k/month - Various smaller companies and legit startups.  I think normal finance-tech jobs are in this range as well.
• ~$2-4k/month - Less prestigious (or non Bay-Area) start-ups or small tech firms.
• ~$0-2k/month - Summer of Code, non-profit work, non-funded or silly start-ups.

* Note: I'm including housing in all of these. 

Keep in mind that a number of these companies also adjust by year, more willing to pay a rising senior than a rising freshman.  I've seen this be a factor of up to 50%.

[edited with suggestions from Hacker News comments]

http://techcrunch.com/2012/04/15/stop-looking-for-a-technical-co-founder/

A pretty surreal/cool experience. I should expand on the process at some point.

Planning to be an Intern in the Bay Area during Summer 2012? Make sure to read an Intern's Guide to the Bay Area, and join the 2012 Facebook group.

 (via this guy, via this guy)

Joel Spolsky, from the Joel On Software blog and StackOverflow, wrote an article with Advice for Computer Science College Students back in '05. According to Joel, 

No matter what you do, get a good summer internship.

As such: here’s everything you ever wanted to know about tech internships, plus some bloviating about my experience. The TL;DR is, try to have at least two internships: one at a small start-up and one at a tech company.

Wait, who are you?

I'm a CS senior at the University of Pennsylvania. I have interned at Facebook (Summer 2010), where I worked on application privacy, and as a generalist at 2bkco (Summer 2011), a new startup from serial enterpreneur Caterina Fake (Flickr, Hunch).  Both internships were great and invaluable. They were also very, very different, in terms of both the type of work I had to do and what I gained from the experience.

1) How do I get a good internship?

Luckily, a number of great posts have been written about this subject already.

• Andrew Munn has a great piece on interviewing and applying for tech internships, focusing primarily on what larger companies are looking for.
• Gayle Laakmann, author of Cracking the Coding Interview, has a post on the difference between what startups and tech companies are looking for.

To which I add my two cents:

• Start thinking about summer internships around Winter Break. Make a list of potential companies and start applying.  Don't be worried if the entire process takes until April or so, though.
• Get a referral rather than applying directly whenever possible.   Ask upperclassmen you know (think: TAs that like you) who could make a referral.  For earlier-stage companies, if they don't have an explicitly-listed referral program, don't worry about it: email the CEO. Hint: they are probably at firstname@startup.com.
  (via Hugh MacLeod) 
• Practice technical interviews. If you're nervous about writing code on the whiteboard, try some combination of being drilled by upperclassmen, buying (and practicing going through) Gayle's Cracking the Coding Interview. Others also recommend interviewing with the companies you aren't as interested in first, using them to train.
• Optimize for what you can get. Bigger companies are going to (generally) look for a high GPA and good performance on brain teasers.  Smaller companies are going to prioritize a history of initiative and automony, as shown by cool projects on your resume.  If you've got a high GPA (at least 3.7 at Penn, say) and are good at brain teasers, you should be OK with larger companies; if not, start with a start-up.
• Your timing is great! Literally everybody is looking for software engineers right now, and internships are one of the key ways to recruit for companies. The market could not be any better for us. If you feel like you're not getting anywhere, make sure to apply beyond whatever is immediately available on campus. Competing with the general populace may be easier than competing with others at your university.
• Consider a mass-application or 'summer program', which are often offered by venture capital firms and have gained popularity in recent years.  Make sure to check out (and potentially apply via): hackNY fellows, Andreesen Horowitz, First Round Capital, True Ventures, Kleiner Perkins Fellows, Bane's StartUp Academy, NYC Turing Fellows, InterviewStreet and InternMatch. None of these are a substitute for applying to companies individually (and I haven't tried them myself) but given the reasonably short time required to apply, they are probably worth doing.
• Location is a pretty big deal. Try to be in the Bay Area (Silicon Valley, San Francisco, Mountain View, Palo Alto, etc) if you can - it's awesome. and there are a ton of other interns around.  I hear New York is getting pretty fun as well, but don't have any personal experience. Other tech regions like Boston or Austin (and maybe LA and Philly) aren't bad, but make sure not to get stuck in the middle of nowhere, living in the suburbs as the only tech intern at a huge company.  That does not a fun summer make.

2) How do I pick where to apply/work?

Before applying, consider: "Am I excited about the products this company makes? Would I be excited to know that I work there?" It's much easier to get motivated (and show excitement) for a company you are excited about. I was Dropbox user #2001, which I did not neglect to mention when I applied. It helped. I think.

I strongly advice looking for internships with a big tech company or a startup, rather than a non-tech company (esp. financial) company that happens to have engineers. The explanation is a little long, so I'll just assume you nod along hummingly here. For the inquisitive: here's a longer argument.

Picking a startup
You want to work for (and learn from) the start-ups that are going to be successful, but as the Venture Capital industry knows full well, it's not always easy to pick winners.

There are, however, a few hints that you can pick up on and prioritize for when thinking about where to work:

• Has the founder had a successful start-up venture in the past? They must have done something right; past performance appears to be the best guarantor of success for tech enterpreneurs.
• Is the founder (or a large portion of the founding team) technical? Are they writing code? Do they come from a strong technical background, whether at a startup or from a top tech company?
• Does the company or its employees have a track record of being good mentors?  I wrote a Mentorship Checklist: questions worth asking to find out.
• Is the company pre or post "product-market fit?"  That is, are they figuring out what the heck it is that they are going to do that makes money, or have they figured it out and are trying to scale and make sure the servers don't melt with all the new traffic?  Both are exciting times in the life of a start-up; consider a pre-product market fit company if you're looking to get a big opportunity to contribute creatively and try new things, and a product-market fit company if you are interested in the technical challenge of quickly scaling a codebase.
• Is this a 'well known' startup? One of the downsides about working at a startup is that it doesn't usually yield the brand recognition of a 'Facebook' or a 'Google' on your resume. Working at a small company people have heard of (TechCrunch coverage/Twitter buzz being a reasonable proxy for 'heard of') helps negate that. Think (again) Quora, Path, Uber, Square, etc - small teams but well-known products.

Picking between larger companies

• The easiest way to figure out if a larger company is worth working for is by their reputation: ask upperclassmen, friends and professors.  
• Does the company have an official internship program? Does it sound awesome? Can you speak to somebody (ideally from your school, but from the company if not) who has been through the program as an intern? Talk about both intern housing and make sure to run through the Mentorship Checklist.
• Sites like glassdoor.com, which offer anonymous feedback from employees, a tremendously useful service as you try to figure out if this is one of those 'magical companies'. The sample size is not large enough to use for companies smaller than a few hundred employees, unfortunately.
• It's not always immediately clear whether a company is or is not a 'tech company' - Amazon and Barnes and Noble both sell books online and have e-readers available, but (from my intuition) Amazon is a tech company that happens to sell books on-line, whereas B&N is a book retailer that has been forced online and into e-readers by the prevailing winds of change. Which one sounds more fun to work at?
• One sign of an innovative company is a technical or product person in the CEO role - think of Larry Page's involvement with Google products compared to somebody like Lowell McAdam (who?) at Verizon.  It's more fun to work for a culture trying to build the future than one trying to maximize this quarter's revenues and 'maximize shareholder value.'
• In general, newer companies will have less middle-management cruft and set-in-their-wayedness than older ones.  There are some older companies with solid programs, like IBM's Extreme Blue, and some newer companies with terrible reputations I would advise against.

3) What you learn
(or at least what I learned)

In short, working with top technical people will teach you software engineering 'done right' (IE, no more turning in ugly code for your homework assignment that is going to be auto-graded once and then filed away forever). That means different things at earlier and later stage companies, though, and I can only relate my experience.

What I learned at Facebook
First and foremost, I learned to write 'good code'. My first non-trivial commit (15 lines or so) was rejected 6 or 7 times until I finally put the right amount of spacing in an "if (" and fixed my trailing whitespace. These were important, brilliant engineers politely telling an intern, time and time again, something that he should have found in the coding guidelines doc. I've been a little bit embarrased to show a lot of my pre-Facebook code, as a result - the improvement, at least for me, was significant. 

In general, the experience taught me that Code is Culture. The fact that top FB engineers were willing to spend so much of their time on code reviews was a fantastic way to show-not-tell Facebook's commitment to good code. I can't say that I've been able to pay the overhead of 100% code reviews on every project or team I've worked on since, but having the background of working in a 'code quality matters' team has infused the way I think about programming today.

I also learned that engineers are not immune to politics, even at great companies. I was playing around with a hackathon improvement to one of the sharing features, but the engineer who understood most of the code would not reply to my emails for weeks and claimed he was busy (which he was) when I walked over to his desk. My original pitch for the feature I wanted to work on was "You know what sucks about Facebook? X.  We should fix it." In retrospect, I did not do nearly a good enough job of trying to get the person on board or show respect for the work that had already been done.

What I learned at 2bkco
I joined the team several weeks after the engineering work had begun. It was very humbling to see the ease with which Eric would put together a component and then decide, several days later, that there was a better way to do something and throw it all away. When you know your code has a good chance of being thrown away, the priority becomes writing quickly in a way that can be cleaned up later (which is different than writing sloppily or writing 'homework' code).

I also got a lot of training in breadth: 2bkco required me to be close-enough to fluent in Javascript (Coffeescript), Ruby on Rails and HTML/CSS. It was too early in the life of the company for me to specialize, which meant a lot of time on Google and StackOverflow, learning how to do a ton of things as I went. I became much more comfortable forking Github projects of things that did sort of what I wanted.

Fin.

That's it. That's all I've got. Mostly. Comment with questions, or just tweet me, yo.

Some valid points brought up via this post's discussion on Hacker News.

Planning to be in the Bay Area during Summer 2012? Make sure to read an Intern's Guide to the Bay Area, and join the 2012 Facebook group.

...I see you're still here. Alright.

PS. What about other types of internships/summer activities?

I spent the summer after my freshmen year doing all sorts of odd things, from playing a lot of Settler of Catan online to working in recruiting for my father, to travelling around in France. It was a mixed bag, unstructured in a way that (in retrospect) I found less than ideal.

There's nothing to say that working all three summers is strictly necessary, or that the two internship types I recommend are your best options (though I happen to think so).  Here are some other options for either a third internship or an alternative to the first two, in something resembling-but-not-quite a ranked order.

• Intern as a Product/Project Manager - A lot of larger companies offer these; though they require a technical background, day-to-day involves more management and product work than coding itself.  Harder to get (as far as I know) than a software position, but worth trying if you are interested in that sort of thing. Google has a particularly prestigious APM position that appears to be a blast from what I've heard.
• Research - find a professor you like that is working on something cool and spend a summer in their lab. This doesn't pay quite as well as an internship but is worthwhile doing if you are considering getting a PhD and want to experience the research process first hand.  This is also worth doing earlier in your undergraduate career, since the positions seems generally easier to get and the work you do will help with internships later on.
• Open Source - consider applying for Google Summer of Code or contributing to one of Apache's projects. Again, the pay (if you are in a structured program) isn't as great, but you still get to learn a ton from talented developers and get the feeling that you are contributing to something that a lot of people depend on.  Again, having a substantial open source contribution is a great resume builder. 
• Freelance/own projects - If you've got the self-motivation and enough HTML/CSS/simple back-end skills, everybody and their mother seems to want a simple website built for a few hundred bucks.  Spending a summer working on a lot of simpler projects is helpful if you're interested in learning the business side as well as pick up pretty good design skills - just make sure to be in an area with a designer/developer community, so you have more than the internet to rely on for finding clients and getting advice.
• Work for a small dev shop - A lot of higher-end freelance and consulting in the US is done by small freelance shops like ThoughtBot and (originally) 37Signals. A lot of innovation in software development (Ruby on Rails, for example) has come from shops like these.  Plus, working on a lot of projects means a lot of breadth. The caveat is that the pay isn't as good, the deadlines are set in part by the client's needs, and there is less creativity on the product end.
• Non-technical internship (or travelling, or non-profit work) - These can be fun, but if you're looking for a career in tech, make sure that your non-technical internship is not done at the expense of getting enough coding experience by the time you graduate.  Companies looking to hire you as an engineer will be far more interested in what coding work you've done than in anything not directly related.
• Tech internship at a non-tech company, especially in finance: Most of these will not pay as well and not (typically) have first-class engineers. Finance is an interesting case here: the pay can often be several times larger, if you are working on algorithmic or high-frequency trading (largely at smaller firms run by technical people). Still, in most finance firms, the traders are first-class; I've had some friends who have enjoyed their finance internships, but a lot have not. Buyer beware: the difference between a $5k and a $7k a month internship doesn't buy happiness.

PPS. Notes for International Students

Update - didn't do your undergrad in the US? You can still do an internship via a J-1 visa. Jori explains.

In general, the situation is a bit of a mess. But: if you're studying in the US on an F-1 visa like I am, here's what I've learned:

• After you graduate, you are allowed up to 12 months of OPT to work in the US without needing an H1-B or similar visa, which is great because H1-Bs are non-trivial to get.  You also get 17 months after that, via the STEM extension (ask your International Programs office).  
• There are two ways you can stay for an internship in the US in the summer: OPT (Optional Practical Training) and CPT (Curricular Practical Training).
• Applying for OPT means you need to apply by February or March at the latest, and (eventually) have an offer letter from your company.  Unfortunately, the time you take eats away from your post-graduation OPT allowance.  Larger companies will be better suited than smaller ones for dealing with the paperwork that OPT entails.
• Applying for CPT is much faster (the University, rather than the State Department, approves these), but CPT means that you're taking an independent study with a professor as part of your internship (for me, this meant writing weekly reports). It also means you're paying for your summer class, which cuts into your profit from the internship.  It does not, however, cut into post-graduation OPT time. Speak to your department about precedents of CPT being done - generally, somebody will be familiar with the process.
• Alternately, if you work on campus, there is some sort of interesting exception where the work doesn't need to be under either OPT or CPT. 

The flight landed at 11:18 pm. The first bags came out 40 minutes later. Mine came out just after midnight, so about 48 minutes after landing. People were pissed off, wondering (correctly) if anyone at all was dealing with the baggage. At one point a small purple bag came out and drifted around unclaimed and disappeared. Nothing else came for at least ten minutes after that.

“They’re totally just fucking with us,” the guy next to me said to my face. “They don’t care at all.”

- Mike Arrington, via http://uncrunched.com/2012/01/15/delta-flight-1642-sea-to-jfk-did-not-suck-nearly-as-much-as-i-thought-it-would/

This got me thinking.

Why don't airlines or airports offer a service to just deliver your bags to your address later that day, without you waiting for it?  I usually use a $10-$20 fixed-rate shuttle to get home from the airport - why not do the same thing that you do for me, but to my bags? Offer it when checking bags online:

[ ] - Deliver bags to your address in destination city and save time when you land - $19

They do this with lost baggage anyway. If somebody is picking you up from the airport, this eliminates a lot of uncertainty in when they should show up. Your customers have one less reason to dislike you.  You can even make a deal with major hotels to subsidize those fees as an incentive to book a room there.  In the long run, you can eliminate space at the terminal by getting rid of a number of carouselles.  Apparently the service already exists in Japan.

Why not?

I've known about Kembrel in a sort of by-the-way, there's-also-this-clothing-company sort of way for a few years now (I think I walked by a Kembrel physical sale last year), but never bothered to figure out what exactly it was that they did.

Until a couple of weeks ago, when Meeteor suggested I meet Stephan, one of the founders. So I did; here's his (and Kembrel's story).

Who is Stephan?

Now he's the CEO (or Co-CEO, I'm not quite sure - whatever, he's one of the guys in charge) of Kembrel.  

OK, so what's Kembrel?

The Kembrel thesis, according to Stephan, is that college students are an appealing market for retailers (starting with fashion), an easy argument to make if you consider the future value of a wealthy customer whose tastes are being shaped today.  College students are not, however, being well targeted by traditional fashion brands.  

Flash Sales

Kembrel's initial solution to this was flash sales, a Gilt-style approach of offering deep discounts on a limited inventory of high-end merchandice in a limited time period. Clothing brands have unsold inventory that they need to sell otherwise and hopefully not hurt their brand by selling it at a low price. Flash sales, online and offline,give the brands an opportunity to both offload their excess inventory, while at the same time growing relationships with potential future customers.

The sales were successful, and Kembrel is now popular in a number of larger college towns.  

Customer Acquisition

I've been thinking about customer acquisition lately, primarily because it's not obvious to me how to do it cheaply enough for a project I'm playing around with.  There's no one silver bullet, according to Stephan, but one thing that has worked well consistenly has been partnering with other brands that target college students, from CollegeProwler to textbook rental websites.  "CollegeProwler is almost an ideal partner," he explained.  "It's students before they are even in college, to already get them thinking about Kembrel and make that association."

Kembrel: Evolution

As their popularity grew, explained Stephan, one concern with flash sales was the high fixed cost of the sale. To do a good job, the seller must synchronize the items being sold, get them shipped, take photos, write up a high-quality description, hire a designer and/or a director -- all that for a set of products that will be on the site for less than a week.  Even Gilt Groupe, who are aiming to IPO in the next several years, is rumored not to be profitable based on their flash sales today. Scaling flash sales is hard.

As a result, Kembrel has recently been diversifying, experimenting with a number of additional revenue models, from a straight-forward (though still discounted and targetted at college students) online shop, as well as considering physical locations, the first of which (at 1219 Locust St) I visited earlier.

Over the next several months, Stephen and the team are playing around with opening additional stores and measuring and learning as much as they can.

Fin

So, that's Kembrel. I understand what they do somewhat better now, and hopefully you do as well. Thanks for sitting down with me Stephen! Looking forward to seeing where you all take this company next.  

• Shop online, try it out in person: Kembrel gives hybrid retail sales the old college try (venturebeat.com)

[Context: I'm one of the Dining Philosophers, the Computer Science Club at Penn]

InterviewStreet offered to sponsor a Study Break to help promote their upcoming CodeSprint.  We contemplating doing a study break, but given that it's finals week and most people are working at home, we weren't sure what kind of turn-out we'd get for an event blocks away from where most people are.

We brainstormed for a little while about what to do instead, and came up with the idea of post-exam hot cocoa and doughnuts, which we've been serving as a surprise to a number of the larger CIS classes immediately outside their final.   

Results

The treats have been pretty well-received so far, resulting in people hanging around a little bit after the final, chatting with their TAs and one another and de-stressing in general. It's been great knowing that we've made finals a little bit nicer for people without forcing them to brave the cold and go somewhere for a study break.  

All in all, the initiative has been a win.

Best Practices

Both for the purposes of future generations of Dining Philosophers and for other schools/clubs that may want to have a similar initiative, here's how we did it and what we learned.  Some of this seems obvious, but helpful:

• Setup Requirements: The food can be served with an hour's preparation and 2-3 people.
• Amount: We bought a jug of 'serves 10 cups' hot cocoa per 30-40 people and a doughnut per every other student. That ratio has been pretty good (we end up having a bit too much hot cocoa).  
• Source: We've been buying from Dunkin Doughnuts rather than making our own Hot Cocoa, primarily because we've all got our own finals and CVS happened not to sell Hot Cocoa Mix when needed.
• Price: We're hovering just below $1/person/final, which works for us.
• Extra things you'll need that you don't think of until 20 minutes before: 
  • Knives (to cut the doughnuts in half before you serve them - just get plastic knives from somewhere, 
  • Napkins (make sure Dunkin gives you a few)
  • Cups (Dunkin wanted to charge 25c/cup beyond 10 cups/jug, so we bought an extra 50 foam cups from CVS)
  • A serving table - make sure to scout.
• Alternatives: Some of these students are in >1 of the classes we're hitting.  We're thinking about switching it up to Hot Cider and Cookies, but that may take slightly more setup time. Ideas?
• Coordination:
  • We gave the TAs for the courses a heads-up (and asked them to help with logistics where needed) but didn't tell the professor until just before.  Doughnuts feel more fun as a surprise.
• Advertising:
  • We stayed away from blatant advertising/taking credit, instead leaving subtle DP signs on the tables.  Students are tired. This isn't a good time to throw leaflets at them about jobs.
  • Our plan for CodeSprint advertising is to (instead) email the CIS list-serv after finals and, as we remind students about CodeSprint, mention that their funding helped the doughhnut-and-hot-cocoa missions.  This seemed like a pretty reasonable balance from our end.

A lot of this stuff seems obvious, but I figured having best practices documented somewhere can't hurt.

Do comment/share if you do something similar at your school, have ideas or know that something like this is already being done somewhere.  

I gave a talk to the Wharton MBA E-club (I think?) earlier today about the difficulties of finding a technical co-founder.  If I find the time, should probably turn this into a post, but for now, slides for the curious 

Also available at git.to/cofoundertalk

TL;DR:

Cheat Sheet

• Don't spend your time looking for a technical co-founder, it's not an efficient use of your time. Instead, either:
  1. Learn to code
     • Step needing to rely on others for execution
     • Meet technical people
     • Managing technical people becomes way easier
  2. Get an external team
     • Don't offer equity
     • Agile:
       • Weekly useful versions of the product
       • Pay weekly or hourly
       • A successful project doesn't 'end'
     • Peanuts ==> Monkeys
  3. Avoid a 'tech play'
     • Use white-labeled 'off the shelf' services where available
     • Fake your back-end: launch with only a pretty design, do hard work manually
     • License the tech from a company in a different vertical or geographic location
• Other takeaways:
  • No NDAs
  • Get a technical advisor
  • Ask for advice, not employment
  • Co-founders are looking for competence and traction

PS. You should me on twitter @alexeymk

I'm a DP columnist this semester, writing once every two weeks for the school newspaper on technology and entrepeneurship.  The below is a reasonably useful list of applications that students should be using, both for Penn students and college students overall.

Non-penn specific apps

...see the rest in the article here.

Dear Future Intern,

Welcome! You just got an internship at this amazing start-up, so you're starting to look for housing and are getting pumped for your summer. Rightfully so - the Bay Area is awesome!  

I spent my last two summers out here as an intern, first at Facebook and (am currently at my last day) at 2bkco, an early-stage, awesome start-up.  It took me a while to figure out what the things to do were out here, especially as the only intern at a small company.  Hopefully, the following will get you off to a running start:

[Note: What'd I miss/get way wrong? Let me know in the comments]

Housing

Where should I live?

Live in San Francisco, Mountain View, or Palo Alto.  As far as start-ups go, San Francisco is more artsy/hipster-ish/design-friendly, with a ton of startups mostly in the SOMA district and (from what I can tell) more reasonable working hours than down in MV/PA.  If you want a well-rounded summer, San Francisco means that there is a ton to explore around the city without going to the same place twice, from dive bars to fantastic restaurants, to Golden Gate Park to Mission Burritos.  San Francisco is fun.  I lived in Mountain View during my summer at Facebook; some friends bashed MTV as being a dead town, but I don't necessarily agree - Castro Street is a reasonable downtown, and so long as you know other interns/people in tech, you're not going to be bored. Palo Alto is just north of MTV (45 minute bike ride), a bit more upscale/happening, but therefore more expensive. 

Your mileage may vary if you live anywhere else - from what I've heard, it's tough to get out to events and there just isn't the critical mass of other interns/people from tech.  I have been especially advised not to live in north San Jose.  There area also areas of SF you don't want to live in - the Tenderloin, most of the Mission, parts of SOMA. Check out this amazing map that figures out neighborhoods in SF based on Craigslist postings.  Also make sure to check out the Walk Score of a place before agreeing to live there and aim for 75 or above.

How do I find housing/How much should I pay?

Figure out who you are going to live (probably friends from college/general friends also out in the area) and start looking. Early. Looking for housing sucks and the market is pretty competitive, so just try to get it out of the way as early as you can.

Note: it is really hard to find a more than 4-or-so bedroom house in SF. We were looking to put together a huge hacker house and it completely fell through just because of the types of houses that were on the market.

Expect to pay about $1,000 per person per month - slightly less in Mountain View, perhaps.  You can try to find something cheaper, but we were at the point where we were ready to pay up to $1,100 or $1,200 a person a month just to get something.  

In terms of tools, PadMapper is a fantastic layer on top of Craigslist that helps you look for houses that fit your criteria, including subscribing to new listings via email.  I'm still waiting for a somebody to solve Housing to Bay Area interns by owning mass inventory - I spent at least 15 hours over spring semester looking for housing.

Weather: A quick aside: San Francisco is consistently at around 55F over the summer (light jacket and jeans) and Mountain View/Palo Alto are at around 75 (t-shirt and shorts or jeans).  It rains in SF, but very rarely.  FYI, so you know what to bring.

Transportation

Public Transit

If you are not in San Francisco, try to be somewhere reasonably near your Caltrain stop - you'll be going around the Bay Area reasonably often.  I've had friends live 30 minutes away from a Caltrain stop and barely ever hang out with us as a result.  FYI: It takes about an hour to get from Mountain View/Palo Alto to San Francisco on the Caltrain. Bikes are welcome.

In San Francisco, public transportation is surprisingly awesome.  BART is the express let-us-get-you-to-popular-places line and MUNI is the normal, comprehensive transporation grid. I lived a 10-minute walk from a BART stop and was very happy with that.  

From everything I've heard, the VTA (Mountain View to San Jose, as well as other routes) sucks.  Don't depend on it as a primary mode of transportation.

Aim for a short (<60minute, ideally <30 minute) commute. If you're working for a big-enough company (Yahoo, Google, Facebook, etc), these will tend to have shuttles from various places in the Bay Area that drive you to work. Those are awesome.  

Bicycle

I strongly recommend getting a bike, though. I had a 30-minute commute by bike both summers.  It was the only exercise I got all summer, and it was great.  Plus, bikes make it easier to get around Palo Alto and Mountain View, whose public transportation options are nothing to brag about.  Same goes for San Francisco - I'm a 30-minute bike ride from anywhere, and I love the freedom of not having to wait for public transit.  The Bay Area is incredibly bike-friendly: bike lanes everywhere, and awesome bike trails to hit if you're in the athletic mood some weekend.  

To procure a bike, consider one of the following options:

• Summer rental from Stanford's Campus Bike Shop.  Rent an awesome bike for the whole summer for ~$300 and don't worry about maintenance/selling it at the end.
• Buy a bike (either at a new bike store, for about $500+, or off of Craigslist, for ~$200) and either ship it back to your campus (~$120) or try to sell it at the end of the summer, again through Craigslist.  I ended up buying a bicycle and selling it, just to avoid the effort of the Craigslist shopper's experience.  All in all, I depreciated about $200 from my bike over the summer, marginally cheaper than having just rented it.
• Ship one from your home/campus; again, expect to pay about $120 for shipping each way.

Rent-a-Car

Also, ZipCar is apparently friendly to 18+ year-old drivers. I ended up renting a car the old-fashioned way over weekends for road trips, but ZipCar might be cheaper for evening trips.  

Things to Do (tech)

Intern-Specific

The questions an intern (especially at a smaller company without a formal intern program) is going to face is, how do I meet other interns/hear about intern-specific events that I should be going to?  I'm not sure which of the programs/list-servs below are going to persist next year, but here's what was up (that I know of) this year:

• StartupRoots is a non-profit that hosts speaker events once a week, specifically for start-up interns. I only went to one event, but the vibe that I got was that the speakers were interesting and the community of ~50 interns that showed up to most events was a solid one.  The weekly program costs $150 or so (to cover food), and the idea (from what I understood) was that your start-up would pay for that as part of your internship.  If not, pay yourself. It's well worth it.  
• Apparently, there was a Wednesdays.com Bay Area Intern group this summer. Unfortunately, I only found out about it while doing research for this article.
• Your school should have a Facebook Group or a list-serv for people in the Bay Area over the summer. If it doesn't, start one. Ours at Penn was pretty useful.
• Figure out who backs your start-up; I know that at least YCombinator, True Ventures and Andreesen Horowitz had intern programs (or at least list-servs) for interns at their start-ups.  

Any time I would hear of an event over the summer, it would be through one of these groups. It was pretty frustrating, actually, that there was not a single group somewhere for all of these intern/tech/Bay Area events.  In an effort to solve this problem, here's a group for next year.  

Intern Events

Throughout the summer, start-ups and larger companies consistently had fun events for general Bay Area interns. Throughout the summer, I either went or heard about events at Facebook, Stripe, Color, Yelp, Twitter, Bump, LikeALittle, LinkedIn, Mozilla, Twilio, Quora and Dropbox.  Several companies (LinkedIn, Mozilla, Stripe, Quora) held intern hackathons that (from what I hear) were a bunch of fun. 

How do I hear about one of these?  Keep your head up and follow the list-servs above. If there's a particular company that you are interested in, email the recruiter, introduce yourself as an intern at X this summer and mention that you'd love to check the company out/be notified of any such events. Assertiveness is impressive. From my experience, approaches like this tend to work.

General Tech Events

Intern events are fun, but it's also worth checking out what the full-time tech scene is up to.  Some recommendations:

• Hackers and Founders and 106 Miles are two of the tech meet-ups that I've been to and can say were a worthwhile experience to have attended. You meet a lot of people starting their own companies or working at cool companies or just generally interested in talking to other people in the industry.  Github also hosts a monthly drinkup (if you're over 21) which I have not been to but hear a lot of good things about.
• Worthwhile mailing lists that I'm familiar with include Hacker Dojo's and Startup Digest.
• If you're the kind of extrovert that is comfortable meeting random new people, try Grubwithus, which organizes dinners for new/interesting people. 
• If you're super extroverted and all networky and everything, check out my roommate Max Wendkos' post on networking in Silicon Valley.
• Hackathons: There's a lot of them here. If you can't find a hackathon that's happening on any given weekend, you're not looking very hard.  I got hackathoned out somewhere around the beginning of July, so I'd advise not doing more than one a month or so.  Still, some cool hackathons that I attended that will probably be occuring next summer as well: HapiHack, BeMyApp, Mozilla's World Series of Hack and the Muther of All Hackathons.  
• Some of my friends also attended Defcon in Las Vegas; form what I hear, they learned a ton and thoroughly enjoyed the experience.
• SuperHappyDevHouse is a fantastic day-long hackathon/meet-up that is run by the folks at Hacker Dojo, once every six weeks or so. I met a ton of people and thoroughly enjoyed the lightning talks. You should go.

Tech Hangouts

I'm not sure if I've got all of these, but here are some of the cool 'people with laptops hang out here and you can tell they are your kind of people' places in the area:

• San Francisco: Check out Epicenter Cafe in SOMA and The Summit on 19th and Valencia in the Mission.  The Summit is also the I/O Ventures incubator space and has delicious drinks (Berry Bomb Cooler and Loose Leaf Tea FTW) and great food.  Epicenter Cafe's cool too, but they charge for the Wifi.
• Palo Alto: Every time I go to Coupa Cafe, I end up meeting somebody I know from somewhere, or hear an entrepeneur pitch their start-up to a VC or Angel. Kind of fun. No wifi on weekends, sadly. 
• Mountain View: Red Rock is the Coupa Cafe of Mountain View. Hacker Dojo is, from what I hear, a 24/7 version of Super Happy Dev House.

Things to Do (non-technical)

Start-ups are awesome and all, but make sure you actually check out the Bay Area - the weather is fantastic and there are some great things to see.

• Bike the Golden Gate Bridge in SF: Rent a bike if you don't have one near Fisherman's Wharf, and do the two-hour bike ride through the Golden Gate Bridge and to Sausalito, (and Tiburon, if you've got the energy for it) then take the Ferry back.  Bring a group of friends. Sausalito is beautiful, the trip is well organized for tourists and a lot of fun. Don't miss this.
• Walk Around the Santa Cruz Boardwalk: Rent a car or find somebody with one and drive down to Santa Cruz.  Check out the Coney Island-style outdated boardwalk/amusement park (I'm partial to the indoor minigolf course), hang out at the beach (take a Surf lesson if you've got the energy), maybe play some Volleyball. A quick not on Beaches in Northern California: They're pretty cold and windy, and something like two beaches have real sand. Santa Cruz is OK on a warm day.  It's still worth going, but don't expect to swim too much. 
• Napa Valley if you're over 21 and don't mind spending $100 or so in a day, go on one of those fancy Napa Valley Wine Tasting tours (alternately, Bike and Wine tastings are fun too).  
• Organize a weekend trip to LA or a nearby National Park: Rent a car and a cabin somewhere. Book a couple of weeks in advance. Don't expect to find a ton of space for 4th of July weekend. I never went, but a bunch of friends did and they thoroughly enjoyed the experience.  
• Computer History Museum: another "I never went, but this comes highly recommended" things to do in Mountain View.  

That's it (so far).  Let me know if I'm missing anything.

Credit to

• Max Wendkos for his networking research.
• Eric Allen my boss for the summer, for introducing me to Hackers and Founders, Super Happy Dev House, and who knows how many of these others.

PS

• You should follow me on Twitter. I tweet about hackathons and startupy things, and not too often.
• If you're looking for a summer internship, may I recommend 2bkco?  I had a fantastic time (post on that coming up)
• If you're a CS student/hacker on the East Coast, you should check out PennApps, our friendly neighborhood hackathon. It's a lot of fun.

So, you've handed over some hard-earned cash to sponsor a hackathon - awesome! On behalf of hackathon organizers everywhere, thank you.  Let's make sure you maximize your return on investment.  

Aside: why should I be sponsoring a hackathon, again?  I go into more detail here, but the TL;DR version is: meet and recruit top up-and-coming hackers, expose them to your company and build relationships for when they start or join companies.

(1) General Advice:

• Show up.  Seriously.  Figure out who your friendliest outreach person is and have them come to at least part of the event. I recommend sending an engineer or (if you have one) a developer evangelist - they know how to speak the language and represent your company well.  You don't have to be there the whole time, but show up enough to meet the cool kids.  If you're not sure who the cool kids are, ask the event organizer. We know, and are happy to make the introduction.
• Teach.  A lot of hackathons (at least on the college circuit) are preceded by a series of tech talks. Figure out what you are good at - is it Coffeescript? iOS development? mobile CSS?  Talk to the organizers about hosting a tech talk. A big part of the motivation for hackathons is to learn a new technology. Seeing who shows up to the talk, learns quickly and asks the right questions is a great way to both introduce yourself and start building a relationship with the right hackers.
• Be personable. Companies do a much better job when they stop trying to be impressive. Don't send hackathon participants to a generic 'apply' page - hand out your email address left and right and talk to people. In most cases, this will be their first impression of your company. Make it a friendly one.
• Be a good judge.  First, (and this deserves its own post) being a sponsor doesn't necessarily mean you should send a judge, nor is judging the most efficient use of your representative's time.  That said, if you are one of the judges, make sure to (1) talk to the organizer about their criteria (at PennApps, for example, we don't care at all about whether the hack has a business model or not, which is clearly not the case for Startup Weekend.  Participants need a mix of encouragement and feedback; make sure your representative is comfortable addressing a reasonably-sized audience and generally upbeat in demeanor.
• Swag away. At PennApps 2010, Twitter sent us 50 t-shirts with the iconic twitter bird logo.  I still see these proudly worn around the Engineering quad, often followed by "whoa, how'd you get that shirt?" Corporate swag is the clearest win-win-win proposition I've seen - companies increase their brand exposure (to exactly the people they are trying to hire), hackathon organizers have goodies to hand out to participants and hackers get swag they can wear for +3 geek cred. You don't need to have the brand recognition of Twitter, but you do need to give student's a reason to wear your branded shirt. I recommend cartoons - engineers love cartoons.

• Get creative. In September, the Venmo guys decided (without any prior warning) to show up at 3AM with bags full of Geno's cheesesteaks.  I cannot begin to describe the sheer amount of goodwill they generated through that. A lot of students have started using Venmo since; I can't help but think that this is at least in part due to the sheer magic of 3AM Geno's. Another example: in January Arkitech brought massage therapists to offer 15-minute massages, a service greatly appreciated by hackers who had spent the last 18 hours in $5 chairs.

We even got one of the therapists to lead everybody in a stretching exercise.

(2) Specific Advice

You're hiring

• Ask for resumes. Not during the hackathon, though - that is neither the time nor the place. Instead, ask the organizers if they might be able to help with recruiting as part of the sponsorship package. For PennApps, we collect resumes from participants opting in, (usually about 50% of participants) organize them into a spreadsheet, group them by hack, and send them to sponsors.  Even if your hackathon doesn't do this, take a look at what has been built (either by attending the demo session or looking through the demos online) and ask the organizer for introductions to your favorite several applications.  Be careful to be specific about this: as an organizer, I'm much more likely to offer to help if you've shown interest in things people have built than if you just ask for introductions to the "winners".

• Connect and follow up.  When you have somebody attending, make sure your representative writes down contact info/emails for anybody who they were particularly impressed by. Wait a couple of days (let people sleep the weekend off) and then reach out: "Hey, I was pretty impressed by X that you were working on over the weekend - I'd love to get a cup of coffee and hear what kind of cool stuff you've been working on."  Even if they don't end up working for you, the good kids at a school will, by and large, know one another - leaving a positive impression on one will get them to introduce you to others in their circle.
• Hang out and help. HackNY did this at their most recent hackathon - at the end of the API demos, Chris asked mentors in attendance who were solid at particular layers of the stack to stand up and introduce themselves, IE "Hey, I'm Alexey from AlexeyCo, and I'm pretty good at Python, Ruby and the Facebook API. I'll be around until pretty late tonight so come bother me if I can help!" If you're trying to hire Python developers, establishing yourself as the company that has solid Python coders makes you an attractive place to work for quality Pythonistas.

You've got an API to evangelize

• Knock your demo out of the park.  Demo quality makes or breaks whether hackers get excited about the possibility of using your API.  John Britton, who represented Twilio, knocks these out of the park (here's his advice). You have a couple of minutes to get attention, and you're competing for mindshare right there and then.  If you're just getting started, here's a sample demo format we used as a guide last time around. 

(credit to Fred Wilson for finding the video).

• Make developers feel special.  In January, John not only hung out with us throughout the hackathon answering questions, but also handed out $100's of dollars of Twilio credits to anybody that talked to him about using the API. As a developer, that's great - this company respects me enough to give me special treatment - now I definitely want to give them a try.

You're an angel/VC

• Connect with future dropouts.  Ask the organizers who they think is most likely to stop out of school.  See what they're working on and give feedback.  Especially in the current climate, building relationships early on helps make the difference when entrepreneurs seek investment.  Seed funding is raised through lines, not dots. 
• Help your portfolio. "Oh, you're passionate about marketplaces and design?  Let me connect you to the folks at Etsy - you might enjoy talking to them!" Figure out what skills and culture your portfolio companies need and keep them in mind as you meet participants. 

... Now that you know how to get the best bang for your sponsorship buck, can I interest you in sponsoring PennApps in September?  We throw a mean hackathon.

PS 

Interested in hosting hackathons? Check out the rest of my posts about lessons learned:

• Convincing sponsors to give you money
• What to do when: The organizer's checklist
• The hacker, the talker and the runner - the hackathon organizing dream team

TL;DR: Friend everybody you can on LinkedIn, then write recommendations for people you actually feel you can endorse.

I've struggled to keep my LinkedIn connections limited to people who I would feel comfortable vouching for, but all that led to was an inbox full of ignored invitations from people I met at tech meet-ups and fellow Penn CS students.  

And now I look bad, both because I'm rejecting these perfectly reasonable people and because I don't have the status of '500+' connections on LinkedIn.  

So, I give up.  Here's my new LinkedIn friending policy:

If we've met in person or online, and you are not a jerk/crook/philanderer, I'll accept your LinkedIn request.  Let's be contacts!

The down side

As the number of connections on a social network goes up, the strength and value of the median connection will, as a rule, decline.  For LinkedIn, it means that people looking for introductions are going to have a far lower success rate asking for referrals. Referrals are (as far as I can tell) one of the key value propositions that LinkedIn offers - a lower success rate means less value.

Increasing signal through recommendations

 I'd still like a way to indicate that I am confident enough in somebody that I would be happy to make introductions or vouch for their work. So, for people I've worked with, I'm going to start using recommendations. My recommendations are:

• 'invite-only' - you can't ask me for one directly, and I won't ask you for one either. A compliment paid begged for has far less value than a genuine endorsement.  I'll be linking to this article at the bottom of each recommendation to make the invite-only nature clear.
• personal - "Hard worker, good communication, smart" sound like platitudes and boilerplate. Recommendations deserve better.
• immune to 'grade inflation' - it's not enough for us to have worked together. I have to be thoroughly impressed by you, both professionally and on a personal level.  The fact that endorsements take a while to write means that I'll be writing less of them.
• a sign of personal affinity - if I've recommended you, feel free to ask me for help however you may need it. I've got your back.

I'll go first. Here are three people I've worked with that I endorse without hesitation:

Mark West - Manager, Moore Business Office, School of Engineering, University of Pennsylvania

When we were seeking funding for PennApps, we (the CS club) briefly considered starting a LLC to avoid the hassle of dealing with the University system for finances. Working with Mark convinced us single-handedly to stay.  To our first email with Mark, asking about processing Credit Card payments for sponsors, he replied along the lines of "unfortunately, we can't do it that way. Here are some possible work-arounds... let's reach out to X, Y, Z and see what we can do."

Mark made a usually painful process of accounting human and entirely manageable.  He has answered emails on weekends, reached out across the University on our behalf and taken time out to double and triple-check our records.  I thoroughly endorse him.

Eric Londaits - Freelance Web Developer

Eric was one of the best developers we worked with at fbDevDir.  Usually, the process that I would go through would be to assign a task, follow up a number of times to figure out deadlines, and then spend a large amount of time arguing about issues of polish and bugs.  

Eric is great.  He work quickly and answers emails with considered responses.  The thing that I loved most about working with him, however, is that I didn't feel like there was a need to manage him at all - Eric cares about the quality of his work and does fantastically well with loosely-defined specifications. He combines an understanding of design and user experience in addition to development which means that he can be a one-stop shop for building cool stuff.

Eric was, finally, the developer (and largely the designer) behind look.fo/str8.to.

Amalfitano, Matt - Former President, Undergraduate Asembly, University of Pennsylvania

Throughout his tenure as President, Matt was a leader and a driving force for change at Penn. I worked with Matt and his team closely during the creation of PennApps and PennApps Labs, working to encourage the administration to support student innovation and open up data for developers to build on top of.  

Amongst other things, Matt is responsible for helping secure funding significant funding for PennApps Labs, both from the Student Government and the University. I am not the easiest guy to work with - throughout our experience, Matt has been patient, understanding and open-minded. Though the movement Matt has helped begin is only starting, it wouldn't have been possible without Matt's strong and unwavering support.

[Matt also helped with disaster recovery. Worth watching]

This goes without saying, but: if you're not in this list, it's because I haven't had the time to go through everybody yet.

I'd be curious to see how others deal with their LinkedIn overflow.

This isn't quite polished enough to be a blog post, but I'm putting it up for now to make sure the idea is out there. Release early, release often, right?

Via a hacker news post earlier today.

The Internet is at a dangerous inflection point. Facebook Connect is quickly creating a monopoly on identity [...] That's a huge risk to every other company on the Internet. [...] There is a terrific technical alternative to Facebook Connect: OpenID.

[In case I'm misrepresenting the argument, make sure to check out the whole article]

In the comments, I jotted down some thoughts on why Facebook is winning and how I think the monopoly is going to play out:

Facebook's monopoly has come because Facebook Connect is an all-round better product. Publishers get access to easy syndication ("oh, you just joined XYZ? Here are some badges; want to share them on Facebook and let your friends know about us?") as well as higher-quality users overall (Facebook accounts tend to be real). Users get a single login from a service they (mostly) trust and easy integration with their social network ("oh, John's using turntable.fm too? Sweet!").

The brilliance of Facebook Connect is the tie-in of syndication with identity. Logging in with Facebook is a better experience than just registering, for all parties involved. This is why Facebook Connect works and why MSN Passport failed a decade ago.

The monopoly side of things is going to become a problem in the coming years; I for one expect federal intervention in the form of mandating a common federated social networking platform (a la, but not necessarily, via the protocols developed by diaspora). Federation and decentralization is what happened with phones and with email; if Facebook/social networking-style communication is the next generation, it seems like a reasonable next step.

Most users will never tell the difference, at first - Facebook will remain their default client both for login and for reading friends' profiles and news feed. With time, however, competitors will begin to emerge and offer alternate interfaces for either news feed filtration or for identity, opening up space for innovation in a place once dominated by one or more entrenched players (Firefox vs IE, Gmail vs Hotmail/Yahoo/AOL). Early adopters will be using social networking tools but will be able to seamlessly interoperate with people still on Facebook.

Perhaps I'm naively optimistic, but I'd be excited for a future like that. For now, though, I'll stick to Facebook Connect - the bigger it gets, the more likely regulation will occur.

I hope the argument doesn't read as anti-Facebook; quite the opposite - I'm a huge fan.

There are quite a few impressive bloggers within Penn's CS community.  Now, thanks to Yahoo Pipes and twitterfeed it's possible to get everybody in one place:

Subscribe via RSS | @PennCIS on Twitter

Email pennappslabs]at[gmail.com to get your blog added to the list.

- courtesy of PennApps Labs and the Dining Philosophers.  

This is a second in series of posts on how to host a student hackathon, based on my experience with PennApps, as well as from participating in HackNY and PhillyGameJam and the hackathons at Facebook last summer. For other posts in the series, see here.

The first PennApps hackathon took place on September 2010, and was put together during the summer before, working nights and weekends.  Below is a (non-exhaustive) checklist of what kind of things needed to get done in preparation to, during, and after the hackathon.  A list like this would have been useful to me last year as a new hackathon organizer, so (hopefully) it'll be of use to you.  

Note: You can put together a Hackathon in much less time than a Summer, so your mileage on the dates may vary.  

3-4 Months Before

"The future is here. It's just not very evenly distributed"

- William Gibson

Venmo is something of a futurist's dream except that it just so happens to actually exist. Simply put, Venmo is your mobile wallet: either through an iPhone or Android app (or SMS), you send and receive money from your friends. Venmo takes money in from your credit card and withdraws it out to your bank account whenever you'd like. At no point does Venmo take a commission (see below) from you or any of your friends.  

I'm a heavy Venmo user and have been one since about October 2010. I've made more almost 200 payments with just under 50 different people (at least since they started providing stats in January) and have gotten a fair number of my roommates and friends to use it. The service improves my quality of life in  a non-trivial way.

How we use Venmo

• I try not to carry a wallet around, which works except for when we go to food trucks. Usually, at least one of my friends will have cash, so I can Venmo them immediately to pay for my part. Gone are the days of trying to remember how much you owe somebody and whether you've paid them back yet - Venmo makes paying your friend back take less effort than writing the reminder to pay them back. 
• Whenever we go out for dinner, trying to pay with multiple credit cards becomes a hassle (even if the place accepts more than one or two).  With Venmo, one of us will volunteer to put their card down and everybody else Venmoes them accordingly.
• One extremely useful use case we've found has been the "I'm going to Wawa/Starbucks, do you want anything?" scenario. Whenever anybody goes for a coffee or snack run at our house, we ask them to bring things back via Venmo, by paying with a message like "$4.55 for Grande Cappucino with Caramel and Skim Milk."  This way, the payment and the order are in the same place, so the volunteer does not need to write anything down or remember what to get - they just open Venmo at the register and order the relevant items.

• As you can tell, we've fun with the 'message' space in the payment, since the messages (though not the amounts) syndicate easily to Facebook or Twitter. 

  
• Venmo has also been tremendously useful for keeping track of utilities with roommates. We simply have a Dropbox folder with all of our bills; at the end of each month or billing period, the roommate in charge of that bill simply adds the bill to our Dropbox folder and then charges us (with a link to the statement in the account).  As roommates, we've benefited tremendously from Venmo's trust feature: if two people 'trust' one another on Venmo, charges they make from one another are automatically approved (though the sender has 24 hours to cancel the payment just in case).  Trust reduces the friction of paying bills with roommates to opt-out, making it something I don't worry about anymore.

How can Venmo afford to not take a commission? 

The short answer is, VC funding means you're allowed to lose money for a while.

The longer answer is: mobile (social?) payments in the US are a land-grab right now, with competitors like PayPal trying to get into the space, Google buying start-ups that haven't launched yet and phone carriers looking to be part of the solution as well. Mobile wallets have the same (if not stronger) network effects than social networks - if the friends I go out with or the places I go accept the service, I'll use it. If they don't, Venmo is useless. During a land-grab, fees are an unnafordable friction. By leaving its business model discovery to late on, Venmo makes it easy for me to have this conversation:

Dude: I don't have cash on me right now, can I pay you back later?
Me: Sure, just Venmo me.
Dude: Nah, That's too complicated. I'll just give you cash when I have it. 
Me: It's actually really simple: I'll charge you $10 now. Follow the link you'll get in your email, and pay once you've joined. Venmo doesn't take a cut or anything. 
Dude: Cool!  ...wait, then how do they make money? 
Me: See above

Conclusion

I like Venmo and I use it a lot. You should too (follow this link for an invite).  

Disclaimer: I'm unabashedly sticking my user referral code in here.  Also, Venmo as a startup has sponsored the PennApps hackathon, which I helped organize. Also, I'm an investor.

This is a second in series of posts on how to host a student hackathon, based on my experience with PennApps, as well as from participating in HackNY and PhillyGameJam and the hackathons at Facebook over the summer.  For other posts in the series, see here.

With finals over, we are starting to lay the groundwork for the next PennApps 2011 hackathon, scheduled from September 2011. As we go through the process, we're making sure to have an organizational structure that ensures that key tasks have owners who are ultimately responsible for getting things done.

It's (theoretically) possible to organize a hackathon by yourself, but the task is pretty large if done right. At least three distinct skill-sets end up being required:

• Technical Your hackathon is going to need a website.  Depending on the technology being used, you may want to provide simple hosting/accounts for participants or unlock a number of phones if you're offering loaner units.  If you have any sort of popular voting or demos after the competition, that part probably needs to be built as well.

  Somebody who understands and can (at least competently) put together a website and administer a Linux VPS somewhere is going to be helpful. We had several people work on the technical side for PennApps, but having a key person understand the entirety of the tech stack meant that there was a central go-to person who could troubleshoot and distribute work.

  Gareth adds: One thing we found in 7Cubed was that it was a huge headache if we used personal accounts for blogs/website registration/etc. This made it so only a single person could make changes to these resources, which caused a bunch of friction. 
  
  The solution there (or at least one we've been using) is to create a your-hackathon@gmail.com (or, if you don't mind configuring Google Apps, hackathon@your-domain.com) and share the password across the people that neeed to register/maintain everything.  This is not a particularly high-security approach, but works splendidly for something limited like a hackathon.

• External Hackathons require a lot of conversations, from sponsors to judges to the University administration to the providers of the location to the students themselves.  We also ended up working with the University's innovation hub and the student government as well.

  Reaching out and keeping all of these stakeholders happy is a job all in itself, requiring a diplomatic approach and an enthusiasm for convincing people to help you.  In practice, the external person tends to also make sense as a reasonable MC for the kick-off and the person who gets enough sleep during the hackathon itself to be coherent enough to run the demo session.

  Gareth adds: There should be a single person operating external relations, or at least a single person assigned to manage each single external relationship. This prevents the "oh I thought you replied to that three days ago!" syndrome.

• Operational We've found that a hackathon demands a reasonable amount of 'running' during the event itself. From registering participants and making sure they have a place to work and sleep to ensuring timely food delivery to ensuring that judges and speakers are able to arrive on time to are well treated during the event, to running midnight raffles, we've found that having a dedicated "behind the scenes" role ends up being critical to a smoothly-running event.

  Unlike the first two, the operational role doesn't require a substntial amount of work until a few days before and during the event. Bringing in somebody who hasn't spent the past several months sweating over the planning details helped us get a fresh perspective and not worry about the quality of day-of execution.

Your organizational structure may have multiple people wearing multiple hats or certain roles split; regardless, make sure everybody on the organizing team (and probably amongst the participants as well) knows who the go-to people are when questions arise.

[Edit - I consider this post to be pretty out of date (don't start with PHP anymore!) but have not yet updated it.  The one-line answer today would be to use a minimalist Ruby or Python framework (Bottle.py or Sinatra) to get started.

Say you know basic programming, probably through some Java or high school APs, but you've never written a line of PHP or had to deal with anything with Unix. Now you want to get into programming for the web. What should you read/do/etc?  Provided is an early draft at a bare-minimum comprehensive guide.

1.  How the Web/Web Servers work

• simplified, high-level overview http://www.quackit.com/web_servers/tutorial/how_web_servers_work.cfm

2.  Front-end (HTML/CSS)

Update: W3Schools is pretty out of date. Let's use the Google tutorials instead.

• HTML/CSS/(+Javascript): tAdvice from Google Engineers: http://code.google.com/edu/submissions/html-css-javascript/
• New Stuff: Dive into HTML5 http://diveintohtml5.org/ (just do the first couple of chapters, more if desired)

3. Back-end language

If you're just getting started and don't have a particular reason not to, use PHP.  I'm writing this for some work that's going to be done in Rails, but PHP is probably a simpler starting language. I'll include links for both:

Ruby on Rails (Ruby is the Language, Rails is the Framework)

• Ruby: http://tryruby.org/. Sprint through this. If you've worked with Python/Javascript/any other scripting language, you should be on top of this.
• Rails intro. Rails for zombies http://railsforzombies.org/ is the crazy/fun one, http://guides.rubyonrails.org/getting_started.html is the official one. From what I saw with Rails for Zombies, it seems pretty fun.
• Hosting: use http://www.heroku.com/ to host whatever you'll be working on.

PHP: The official PHP tutorials aren't half-bad, but there's a ton of crappy, outdated PHP stuff out there. Googling 'how do I do X' in PHP will typically result in terrible advice; if the site looks out of date, it's suggesting that you do it wrong. Use these as a reasonable starting point if you go with PHP:

• http://www.php.net/manual/en/tutorial.firstpage.php
• http://www.php.net/manual/en/tutorial.forms.php

4. *nix:

You might not need to touch that much Linux (GNU/Linux, if you'd like) to get something done, but just in case, here are the bare essentials:

• Penn CS' unix tutorial: https://www.cis.upenn.edu/~cis1xx/Learn/Unix/Resources/UnixTutorial/
• Version Control - kind of a good idea. Use git: http://chronicle.com/blogs/profhacker/a-gentle-introduction-to-version-control/23064  Also get an account on Github.
• Editors: you'll want to learn emacs or vim. I'm familiar with vim - choose that one (arbitrarily). Use vimtutor to learn vim http://linuxcommand.org/man_pages/vimtutor1.html or just type in 'vimtutor'.

What am I missing? Are there better guides suitable for beginners that I haven't found?

Whoa.  Thanks for all the attention and feedback, everybody! In case you're curious: I ended up emailing the letter to RMS and got a reply earlier today.

I am skeptical of advice from people who disagree with what I stand for.

--
Dr Richard Stallman

Overall, commenters seem to have had fairly positive things to say, but a number ended up arguing against points I wasn't making.  To be clear: I don't think RMS is wrong to argue for Free Software, or that he should somehow moderate his position; I just don't think mentioning 9/11 or the Swindle is particularly helpful to the FSF cause.  If you haven't yet, check out the recording of his talk and judge for yourself.

Finally, I'm incredibly grateful for all of the contributions RMS has and continues to make, but I don't think RMS (or anybody) is beyond criticism. To equate criticism of a tactic with criticism of an ultimate goal does not seem to be an effective way to encourage feedback or open discussion.  I'd love to see an FSF which takes itself seriously through its spokespeople and campaigns, because I think a cohesive and credible argument from the FSF is an important part of the discussion about the future of technology's role in society.

Alright, that's enough buzzwords for one paragraph. Thanks for taking the time to discuss, everybody.

[Edit: here's the original letter]

Dear Dr. Stallman,

Thank you for coming to Penn and giving a talk on A Free Digital Society; it was an honor meeting you. You mentioned that what you expected of us was to help the Free Software Foundation however we could; I'd like to take you up on that and offer both yourself and the FSF the following advice:

Stop marginalizing yourself

You make a number of very valid points. When a program is distributed without its source code, users don't have as much control as they would otherwise. Internet censorship is on the rise and presents a serious and credible threat to society. DRM is an example of false scarcity and doesn't make sense in the long run.  But every time you use the word Big Brother or call the Kindle "Swindle," or make an aside like "even if you believe that the government had nothing to do with the attacks of September 2001," you go from making an interesting argument about freedom to being the crazy guy shouting at cars on the side of the road. 

Most FSF marketing materials follow this "you're not listening to us, so we're going to make increasingly outlandish claims" approach. The closest comparison that I can make between the FSF would have to be the Lyndon LaRouche movement.

There are numerous arguments in support of Free Software that I can think of that do not have to involve a conspiratorialist tirade. When you talk about the risk of software as a service, you can mention that the US gov't is attempting to collect identifying user data from the Wikileaks Twitter account, or the recent domain name seizures of PokerStars and other online gambling websites. These are practical consequences of a lack of Free Software and, arguably, places where the government has been overstepping its bounds.  These are the arguments I would have loved to hear from you, presented in an even tone and without the usual snark.

Baby steps

In today's world, it's not realistic to ask most users to completely abandon all proprietary software immedialy. Proprietary software is usually better, especially when it comes to UI Design and User Experience. When a student confronted you with this, you responded that if we truly valued freedom we would not mind the inconvenience of (for example) emailing copies of documents around instead of collaborating via Google Docs.  

Dr. Stallman, Google Docs is really useful. I imagine you're unlikely to have tried the service yourself, abstaining as you have from proprietary software for the past several decades.  It may be worth trying the service out, if only to better relate to your target audience.

Dr. Stallman, you like to use the argument that proprietary software is like a drug, so let me extend that analogy: today's proprietary stuff isn't marijuana; it's heroin, and it's really, really good. You don't get somebody off heroin by lecturing them about how they should value their freedom; you switch them over to methadone for a while and let them slowly detox.  

To that end, please stop accusing users unwilling to shift to inferior software as haters of freedom; all you are doing is insulting us and inviting us to ignore you. Instead, consider offering practical alternatives and first steps for products that you would recommend.  We live in a world where having the technological edge makes the difference between success and failure; asking us to just give up that edge for a theoretical idea of freedom is not going to work.

Do what you do best

Dr. Stallman, I have a tremendous amount of respect for your contributions to GNU, emacs and gdb amongst others. You are a man of considerable intellect and programming ability. That said, I nor the people that I spoke with about your talk found you to be a particularly charismatic or persuasive speaker. The only people that seemed convinced by your speech were the ones who had already been leaning towards your point of view to start with. Several friends of mine who had not heard of the FSF before left half way through because they were so put off by some of conspiratorial rhetoric above.

I wonder whether the Free Software movement might be better served if you spent more of your time mentoring up-and-coming hackers and writing free software that matches in elegance and quality some of the software that you have written in the past. When we asked, you mentioned that you do not write much code anymore. That's a shame.

[Edit: Dr. Stallman responded]

I was at HackNY over the weekend; our resulting demo is below (starting at the 9 minute mark).

Given a chance, I'm hoping to put together a longer article about solid Hackathon demos and building the product vs building the demo.

We didn't win anything, but (until my __real__ bug) I was pretty happy with the quality and interactivity that we were able to achieve.

I spent a fair amount of time earlier today trying to set up todo.txt with Cygwin on my Windows 7 boot. For the longest time, I was getting "Permission Denied" whenever I tried to write to files inside of Dropbox.  

This was a result of some misconfiguration of cygwin and Dropbox; long story short, if you run into this problem, chmod-ing the files with the necessary permissions didn't (sadly) work. Stack Overflow suggests playing around with /etc/passwd inside of cygwin, and even offers a pretty cool guide about how Cygwin maps Windows to POSIX-like permissions.  

Ultimately, the solution that worked for me was the simplest one: in Windows, I opened the file and gave everybody full permission for it. 

In case anybody else is keeping count, there are now two Groupon clones focused specifically on the Penn market: CrowdQuest and Lootsa.

These bring to mind Lewis Black's End of the Universe:

When I started this blog, I was hoping to do a bunch of New Yorker-style profiles of cool Enterpreneurs that I got to meet, only considerably shorter and worse. Here's my first.

I met Haig (left) and Jason (right) through John Fazio, who subjected his internship request to my Case Study. 

Haig Didizian (Penn CS '02) and Jason Matson (Drexel MBA '10, amongst other things) are the CTO and COO respectively of 16-person WineAccess, an online wine retailer based near Philly.  From its roots in the late nineties, the company has been creating technology to make the wine purchasing experience better.

Originally, that meant things like making it possible for retail wine shops to list their inventory online and take online orders. When customers checked out, retail shops would collect their emails. Customers would get a "hey, come rate this wine you just had" email and be linked to a site where they could see their historical ratings, get suggestions for wine to try and communicate with other wine aficianados.  "It was a very early Social Network-type thing," explains Jason.  

As the e-commerce market became more competitive, however, creating online stores for shops became a less interesting business, leaving the company in search for alternate ways to grow. It was in that context that Haig and Jason joined WineAccess; this is their story.

Jason had been pursuing a Physics PhD at Florida State and working on his dissertation when The Leaving (Jason's band) was signed by by Milquetoast Records. Jason did the obvious thing, abandoning his studies in favor of a tour that lasted a full 3 days before the label imploded.  The band ended up self-producing their first album and eventually signing with another label, resulting in a fair amount of touring and travelling.

Several years later, finding himself in Cape Cod over the winter and between gigs, the former physics PhD took a minimum wage job as a stock boy at a grocery story. Within a couple of years, his interest in wine - "I liked drinking wine, so it was a good fit" - lead Jason to a job working for a big-box wine and spirits retailer in Massachusets, managing the installation of a forty-foot statue of Captain Morgan.  

"I knew the fork-lift operator drank on the job," explained Jason, "and if he made one mistake, that would be it for me below. I had this terrible vision of being crushed by Captain Morgan's giant leg."  Wanting to get into higher-end, fine wines, Jason eventually convinced his wife (who, in a random aside, ran About.com's book series at the time) to move to Philadelphia and work on WineAccess.  

"I met Jim [the founder] for the first time in a coffee-shop after having corresponded online. Jim arrived via bicycle, wearing torn jean shorts. He gave me this three-question quiz about wine. I went zero for three."  Jason got the job anyway, and has done everything at the company outside of programming (VP of Operations, VP of Marketing, etc) ever since.

Haig was a Penn CS sophomore during the first bubble.  "There was so much interest in tech that the Wharton Tech Career Fair was held in the Penn Convention Center downtown, comprising three full blocks," he explained.

"We showed up, and everybody was there: Intel, Dell, Enron. They were all wearing suits, and we were all wearing jeans.  Then there was this tiny booth in the corner and those guys were wearing jeans too. We were like, 'who are you guys?' And they were like, 'oh, we sell wine, and we just raised a bunch of money.'  I didn't understand any of the fancy words in their business plan, but I don't think they did either." Haig ended up interning at WineAccess his sophomore year of college and doing part-time consulting afterwards. "This was my stereotype of what a cool company was like," Haig explained. "After graduation, I ended up working at a couple of start-ups, and then at Unisys. When I joined, there were 130,000 employees at Unisys. By the time I left, there were 30,000.  They were very good to me, but it was the opposite of what a cool company was like."  Then, on a whim, he called up his old boss at WineAccess to see how things were. The company was growing and needed all the quality manpower they could get. "I said, 'I want to work 3 days a week and not have to come into the office.  Can we do that?' They said, 'Sure!'" As CTO, Haig's hours have since somewhat increased.

What does WineAccess do?

After years as an e-commerce provider to retail wine shopes, WineAccess began looking for ways to evolve its business. Realizing that they had access to hundreds of thousands of email addresses of wine lovers, the company began to market to its consumers directly. From their website, 

That's when we got the idea. What if we sent winery email offers for just one wine or two -- a couple times per week -- wines we discovered from all of our winery connections on the great wine trails of the world? Would anyone care? Was there anyone out there? We tried it. Amazingly, 56 people bought the wine! We couldn't believe anyone was listening. So we sent a few more. Within six months, wineries and importers were calling us wanting to know how could they have their wines featured on WineAccess.

Ever since switching to a direct-sales model (Groupon for Wine, if you will) WineAccess has been increasing revenues 100% year-on-year.  

"Is that like Wine.Woot," I asked. "Are they a competitor?"

"Sort of," Haig said. "They're in a different segment. We both sell wine, but they focus on great deals. We focus on great wines."  The average purchase from a WineAccess purchaser is in the several hundred dollar range.

"We're all about having a good time," Jason said, as we were heading out, "but don't get us wrong: we're working hard, too. We want to own this space."

The Interactive Media Group, (Wharton's undergraduate Social Media guys) invited me to speak about WSCM and working with Penn Engineers. Here are the slides from my talk:

Zach Wasserman created something I've been wanting for a long time and have been to lazy to implement myself: the 'go' command.

Often, I'll be looking for some file on the command line, I'll type cd and be tab-completing and end up getting to the file itself. Of course, "cd ~/my/stuff/file.txt" doesn't make much sense.  

bash: cd: stuff.txt: Not a directory

I end up changing cd to vim, but it's kind of a waste. The solution, then, is to follow the 'click on something' paradigm from modern GUIs: clicking on a directory opens that directory and shows its contents; clicking on a file opens that file in whatever the default for that file type is.  For simplicity, let's just use the $EDITOR for files.

Behold, the 'go' command:

go()
{
if [ -f $1 ]
then
    $EDITOR $1
else
    cd $1 && ls
fi
}

Add it to your .bashrc file. http://zwass.wordpress.com/2011/03/16/the-go-command/ for details.

Thanks, Zach and Andrew.

Jarvus is a web technologies company built on hackers of all kinds (degrees, dropouts, and GEDs) and our mission is to always be developing or working on the coolest technology we can get paid for. We don't have a ton of money, and we're not looking for venture money, because we don't need it. We've been bootstrapped from the get go, and we're growing fast. 

If you're looking for a 9-5 to put cash in your pockets we're not for you. If you're looking for a job that challenges you while you learn and build awesome resume experience, Jarvus is the place. We provide a high-pace technical and intellectual environment that forces students to sink or swim. Those who swim, come away with invaluable technical knowledge and working industry experience. 

We're ALWAYS looking for web development talent no matter what your specialty is, but right now we have a significant demand for mobile application developers with experience in either iOS or Android Java. We're looking for developers to come on board as contractors while training for higher-level development within our framework. Pay rates begin at 20-35$ depending on experience. We've got about 12 months of project work lined up right now and would be looking for someone to fill a position for 8-12 months and train the next in line. Salaries will be negotiable after 1 month if production.

Students who have worked for us have added some of the following projects to their resumes:

• Wharton's MBA Broadcast + Sencha Touch iPad app
• TEDxPhilly.org
• TheRoots.com
• PhillyTechWeek.com
• Educon23.org + Sencha Touch Mobile app
• ScienceLeadership.org

This is a first in a (hopefully) series of posts on how to host a student hackathon, based on my experience with PennApps, as well as from participating in HackNY and PhillyGameJam and the hackathons at Facebook over the summer.

Organizing a hackathon costs money - even without paying for the space, large prizes and t-shirts, we spent nearly $3.5k (~$35/competitor) for PennApps Mobile on food and drinks over nearly 48 hours. How do you raise something like that?

Possible Funding Sources

Here's what has worked for us:

1) Tech Companies (Google, Facebook, Microsoft, Yahoo, etc)

Software engineers/hackers are in high demand. Recruiting is hard, both in terms of gaining exposure and figuring out who the good candidates are. For tech companies, sponsoring a hackathon address both of those issues. Companies gain exposure by giving tech talks about their APIs and sending their developers to come hang out/answer questions/participate as judges.  Being perceived as hacker-friendly helps get participants excited about working for your company; when participants do apply, they've certainly got at least one project under their belt. Further, Students who are passionate enough about building stuff that they're willing to spend a weekend without [much] sleep are an appealing group of students to be hiring. I don't have exact numbers (yet) but it should be interesting to see how many people ended up getting jobs or summer internships from companies they met through PennApps.

The bigger the company you contact, the more used they are to similar requests for sponsorship and the more likely they are to have a budget for it. Local start-ups (or, if a company wants to get its APIs in front of developers, start-ups in general) can often be a great fit since there's a good chance you can get the founders to come judge or hang out with the participants, but may have less immediate funding to offer; in general, secure most of your funding from well-known companies before reaching out to smaller start-ups; if nothing else, saying (though not directly) "Google and Microsoft are already lined up to sponsor; would you be interested in joining them?" helps establish your credibility as you raise funding.

[from Gareth:] Contacting a University Recruiter will tend to go further at a large company than contacting a friend who works there, since recruiters have a direct budget for things like this.  If you have a friend at the company, ask them to put you in touch with the recruiter directly.

When speaking to tech companies, we made a point of getting either places that students are already excited to work for (Google being the prime example) or those with a reputation for treating developers well. There's some sense of responsibility here for getting sponsors that fit in. 

2) Venture Capitalists

Venture Capitalists have two ways to gain from hackathons: as above, they are able to benefit from helping their portfolio companies recruit from the hackathon talent pool for summer or new-grad positions. The added bonus for VC firms, however, is using hackathons to measure the pulse of the developer community - what phones are people using, what development stacks are popular, what kind of ideas are floating around in the aether. There's also always the possibility of finding a great technical team and encourage them to turn toward entrepreneurship, building a relationship early on.    

3) University Entrepreneurship Groups

At Penn, the Weiss Tech House is a hub for student entrepreneurship and was a natural partner for us to work with, providing free space as well as offsetting all security-related costs. In general, if there's a Technology/Innovation/Entrepreneurship organization or group at your university, sponsoring or being part of a hackathon is right up their alley and makes them look great. Even if they won't be able to help substantially with your budget, they'll be able to help with things like convincing university facilities that it's perfectly fine to hold an event that requires keeping a building open overnight. The Computer Science department or CS clubs may also be game for sponsoring if you need it. All in all, your school should be excited about having a Hackathon: it makes them look cutting-edge and tech-savvy.

[From DJ]: Having some University group giving you official support also makes sponsors comfortable that your event has appropriate backing and is actually going to happen. Consider adding your official university affiliation to your website right at the beginning.

4) Local Groups/Barter Deals

Energy drink companies are the cleanest example of this, but there are others: what sort of products are trying to sell their goods to engineering students/hackers and would be interested in free advertising in exchange for their goods?  We've been able to get discounts from new restaurants in the neighborhood, laptop stickers and web hosting (that I can remember).  The value proposition is simple: let's get your product in front of people that are in need of something exactly like this. A couple of days after the hackathon, we'll send out an email thanking the sponsors; hopefully, enough will convert or buy the product next time they need something like this to make it worthwhile.

5) Don't Charge Students

Your goal (or at least ours) is to maximize turn-out. Free food and drinks (and give-aways) for the course of a weekend is a solid selling point. Even something as low as $5 or $10 creates a barrier to entry. I've heard the argument that charging money filters out people who aren't serious about hacking; honestly though, not sleeping for two days is enough of a filter as it is. Charging students isn't worth it, especially given the alternatives.

Levels of Sponsorship

We had a complex system for levels of sponsorship that will probably evolve as we host more hackathons. If you're going to have tiered sponsorship, here's what you should do:

• Figure out exactly the ways you create value for your sponsors; the above is a reasonable starting point. Distinguish the various types of partners you're speaking with; a food truck isn't looking to get the same thing out of a sponsorship as Google.
• At each level, offer substantially more value than at a level immediately below, a clear and obvious reason that adding more money is worthwhile. For us, this was the Resume Drop: at $1,000 or above, sponsors received a resume pile of all participants who opted in, making contacting and reaching out far less of a pain.
• Create a 'reach' sponsorship level that you don't expect to get: for us, this was the $5,000 'IPO' sponsorship level: certainly, fund-raising would have been easier if we got an IPO-level sponsor, but even without one we made the $2,500 sponsorship level look cheap in comparison. Anchoring: make it easy for your champion at their company go his or her boss and argue for the amount of money you'd like.
• Make sure to collect the actual sponsorships well in advance of the hackathon. Sponsors, even well-known ones, have bailed at the last minute before. The safe thing to do here is to get checks (or payments, however you're processing it) from sponsors at least a couple of weeks in advance.

Contacting Sponsors

Ignoring unsolicited emails is ridiculously easy. For tech companies and VC firms, we had a far higher success rate for funding if we first got introduced through a student that had interned or was interning at the company or through a professor who had worked or done research with them. That said, we were successful by contacting recruiters directly at Yahoo and Bloomberg, amongst others; if you can't find somebody to introduce you, going directly might be worth a try.

For the initial email, something like 

Greetings,

I'm a CS Junior at <University>; we're putting together a hackathon (<link>) on <Date>. I was thinking that <Company> might make a great sponsor, since <reason>.  Let me know if this is something you may be interested in and I'd be happy to send your more details or set up a phone call.

<Student Organizer> 

worked reasonably well.  

We made sure to have at least a simple website up before sending out emails, to add some weight to the operation (IE, this isn't just some random dude emailing to ask for money).  We kept our intro email short in most cases; the longer an email is, the easier it is to ignore. We included a line or two in the email about the exact value proposition (IE, "because you're recruiting on campus and this is a great way to get the word out about your company"), both to ensure that there was at least some hint of the value proposition and to avoid the impression that this was a mass email we were sending to hundreds of potential companies.  Finally, the email was sent from a person rather than from an organization, in an effort to make a personal appeal and begin building a relationship with the potential sponsor.

Assuming the company responds, send a longer email detailing the exact value proposition and the possible ways that a company could get involved (sponsor a custom prize, bring a judge, etc).  To start, though, keep it short, credible, simple, and personal.

What have I missed? How have you done things at your school? Leave a comment.

The quality of emails to the cis-ugrad list-serv has received a fair amount of attention recently.  Making fun of clueless wanterpreneurs is good fun, but as many in the CS community have pointed out, it seems only fair to also educate and enlighten about what does and doesn't work.  

Andrew Chen's recent blog post sums up quite well the crux of the irritation Engineers feel when getting emails like these:

I’m starting a online company that has to do with the fashion industry. I saw you through a friend we share in common; I hope this email is welcome.

This is our basic corporate structure:
1. CEO
2. CTO (Chief Technology Officer)
3. VP of Biz Dev/Sales
4. Chief Architect
5. Developers

The irritation is basically this (via Andrew):

Here’s why it’s hard: The nerd perspective is, they don’t need you. Much of the reason why it’s insanely hard to find a really good technical cofounder is that the best ones really don’t need you. Or at least they don’t think they need you.

Because there’s an illustrious track record of engineering-founded companies succeeding, spanning from HP to Facebook, there’s a lot of datapoints that say that a 20-yo Stanford computer science major can do it himself, or at least with his other CS roommates. Similarly, the very best alums out of places like Facebook and Google have lots of access to capital, advice, and people- these are all recipes for making you (the biz founder) completely irrelevant.

and  

Remember this:

They are not the code monkey. You are the biz monkey.

That’s just how it is.

Yes, successful tech companies have been started by non-technical people (Apple, Dell, Zynga); yes, a number of the big successes (Facebook, Google, Microsoft, Yahoo) were all started by engineers. I could go into length about this, but it's not particularly productive.  For the moment, though: we (the cis-ugrad list-serv) are getting way more offers than the amount of time any one of us actually has. Naturally, that leads to being reasonably picky about the opportunities we end up pursuing.  So:

Dear Sender of Amazing Opportunity,

Personally, I'm sure your idea is pretty cool and if you're not going to be successful with this one, you'll probably make out just fine in the end. The fact that you've found the list-serv and are contacting us is a pretty good show of initiative and just for that alone you have my respect.  

Having said that: this email is one of a ton that we're receiving: this is your shot to get us interested. You want to make sure you're doing it right; otherwise, your cool start-up or sweet job offer might just end up as unread junk literring our inboxes. That would suck. With your permission, I'd like to offer some advice on how to pitch your opportunity to CIS undergrads.  

• Keep it short: If your email is longer than a paragraph or two, it's probably too long. Ever look at an unsolicited email on a list-serv and realize it's not worth reading because it would take too long? Exactly.  As a rule of thumb, less than 200 words is probably a good idea.
• Make the offer right away: Your first or second sentence should, with as much clarity as possible, explain what the opportunity is and who it is targeting. People tend to be looking for a technical founder, part-time intern or employee, summer intern or full-time developer who may have a particular skill-set and is looking for some reasonable range of compensation. Are you looking for a first technical employee or do you already have a team? If I can tell the email targets people like me at the start, I'll keep reading it. If I get through the first paragraph and am still unsure what you're looking for, I'll probably keep moving.
• Be specific: There's nothing sillier than a stealth startup trying to recruit without saying what space it's in. I get that you know your idea is one-of-a-kind, but for us it's one of many that we'll read that day. If I don't know what your value proposition is, you don't have a value proposition.  

  This also applies to compensation: way too many emails explain that this is "something we can discuss" or that the compensation is "competitive." Competitive means different things to different people. While it makes perfect sense to offer more or less money or equity depending on the caliber and experience of the potential candidate, if you don't at least give a range, you're making it way too easy to ignore an offer that could have been a great fit.  In case you're wondering what reasonable compensation might be: at least $15/hour is reasonably standard for this type of work.

• Be humble and straight-forward: I believe you; this is an awesome idea. Engineers are by and large friendly, no-bullshit people.  Please don't throw words like synergy and competitive advantage around: they absolutely make sense in the business context and it's great that you're thinking about this stuff. As far as Engineers are concerned, though, this doesn't make you look impressive or competent; it makes you look like a suit who is too focused on business-y things to understand the technical challenges involved in the work. Nothing is more annoying than working for somebody who you feel doesn't understand your job.
• Proofread.  Seriously, if you can't spel or have trouble with ALL CAPS, please ask a friend to proofread your email. Complete, grammatically correct sentences are a minimum requirement.
• Get your (technical) facts straight: Don't ask for somebody with at least 7 years of Ruby on Rails experience. If you're not sure why that's funny, look it up.  There's no simpler way to get your email ignored than to show that you have no idea what work actually needs to be done.  If you haven't invested the bare minimum of time required to do your research, that says something about your approach to technical work. Don't be a pointy-haired boss.
• Why should I work with you? The most painful class of emails we get is the "I've got a great idea, shouldn't be so hard, I just need somebody to do the web design in a week or so" email. First, engineering is not web design (though web design is an awesome and entirely non-trivial task).  Second: it sounds like you're asking us to do something for you for free, just because it's an awesome idea.  Fair enough; but why should I work on your awesome idea and not mine?  There's one of several ways to convince us:
  • Money: If you're willing to pay at least a reasonable rate ($15-20+), that's fair. The idea or job might end up being terrible, but at least it won't be a waste of our time.
  • Credibility: If you sold your last start-up for $XM dollars or you're well known to be technically-competent and willing to mentor people working for you, you're an appealing person to work with and can get away with a far smaller pay-scale or even get somebody to work for free as a learning experience or a way to get to know you. Ironically, people with credibility tend to be willing to pay for work, since they value their ideas enough to not want to easily give up equity in them.  Having other people already on board also helps and is worth mentioning. Also, in case this isn't obvious: getting into Wharton or M&T is not 'credibility'.  We absolutely respect that it's a highly selective process and you're right to be proud of your accomplishment, but there's a lot of you. Sorry.
  • Sheer Charm: Sometimes, non-technical people get by on sheer charisma and persuasiveness. Congratulations to the few who can get away with it.  This route has a reasonably low success rate; if you are going to try it, please at least make clear what you bring to the table. Andrew Chen briefly discusses what these might be - can you pick up design, or copy-writing, or user research?  Can you test?
• Avoid attachments. Don't send your offer as a doc or a pdf: send the offer right in the body. I'm not sure what percent of people open attachments from list-serves, but it's less than 100%.

Yours,
- CS Majors @ Penn.

PS - this list is a work in progress. If you've got ideas on consolidation or other worthwhile advice, please leave a comment.

Check out the case study if you're looking for a concrete example of this approach applied.

tl;dr: We get a ton of emails. Make sure yours doesn't suck or we'll probably ignore it.

I spent Thurs-Sun of this past week in the Bay Area, interviewing for potential places to contribute to this summer and just generally meeting cool and interesting people. Let me just say: the Bay Area is awesome.  The weather is warm. The people (that I met, at least) are incredibly open, willing to listen to some CS Junior's ideas about what they should do with their company and what the future of some technology might be.  

A couple of the VC's and judges that helped out with PennApps introduced me to potential employers; after that, one meeting kept leading to another; I spent about half the time interviewing and the other half setting up meetings for the next day. Now, I've been to San Francisco before; it's not (entirely) trivial to show up and meet people if you're just some dude, but from what I can tell introductions from respected people goes a ridiculously long way.  

Serendipity goes a ridiculously long way; by sheer coincidence, I met Caterina Fake and off-handedly mentioned Whartonite Seeks Code Monkey, a tumblr some CS guys had set up the week before in response to frustration at the cluelessness of many emails that came through our list-serv. Caterina tweeted the link

and we became a minor meme on the tech blogosphere, including reaching the top of Hacker News and resulting in an awesome article from Andrew Chen about how to add value as a business person.  Eventually, even the local college blog got into it. It's ironic that Penn CS ended up getting noticed more for the time we bitched about clueless Whartonites than when we got almost 100 students to spend a weekend hacking on awesome things.  Whatever; we'll get there.  

The point is, this whole thing got started because the Bay Area is awesome. I can't wait to go back.

Here's an email I'd like to see:

Hello there,

I am contacting you on behalf of a next-generation Social Networking start-up that is looking for some ninja coders who know PHP and maybe some Python.  The idea is, you can follow your friends and see what they are up to.  Here's the twist, though - you can "check in" somewhere and then your friends can see and comment on it. It's also a Q&A service.

The company was started by two Harvard students, a Psych and an Econ major.  I don't want to get into too many financial details but we have a lot of really impressive high-profile investors interested in funding us. This is going to be a multi-billion dollar company. For sure.

We have gotten a ton of interest from people who want to work with us so you should be pretty good if you're going to apply.  This is a ONCE IN A LIFETIME opportunity and if you miss out now you'll regret it forever, I'm telling you.

Interested? Apply here.

[As an aside: if you're into this type of thing, be sure to check out whartoniteseekscodemonkey.tumblr.com]

Here's something I've been meaning to do for a while: post a filtered list of worthwhile coding job openings on campus and around. Openings are going to be limited to ones that I think are awesome. As such, the list is going to be arbitrary but useful. Subscribe to the 'jobs' tag if you're interested.

Opportunity:

I'm taking Product Design with Karl Ulrich this semester. As part of the class, we have to come up with and outline 5 potential (physical) products targetted towards college students that are fairly simple and would retail for <$50.  I liked some of mine, so I figured I'd share them and see what people thought.

Ideas:

1.  The Tech-Savvy Student's Padfolio

Laptops and/or tablets are slowly gaining market share amongst students taking notes in class.  A growing market opportunity exists in providing a note-taking tool that students can carry around as "the one low-tech thing I have in my backpack, in case I ever need to take notes or think on paper or if I need to take a hand-out."  Today, I use a padfolio (http://git.to/padfolio) for this purpose, but the padfolio is in no way custom-tailored to my needs.  

I'd like to be able to do things like 

- work on both sides of my paper, 
- easily collate (staple?) and tag/label notes or hand-outs, and
- optimize for an archiving process that takes into account my future likelihood of needing the particular set of notes or handout again.

2.  A bike lock that only locks 'the right way'

As anybody who has ever had a bike stolen will tell you, more often than not, it's their own fault for not locking the bike correctly.  

Standard bike locks sold today are a pain to use correctly. First, we have to find an appropriate place to lock the bike. Then it's a question of getting the frame and the wheel in while leaving enough space to attach the lock and turn the key.  The one time I was in a rush and locked my bike wrong, I was left with this:

There's an opportunity in creating a bike lock that:

- Simply does not lock unless it's locked things correctly and
- Is quick & effortless to install, but
- Is as safe as traditional locks.

Anybody who has had a bike stolen (or anybody whose parents are worried about buying an expensive bike) wants to get a bike lock that only works 'the right way'.  

3.  Cheap Dorm Room Whiteboard Pack

Every design/engineering student should have a whiteboard in their dorm room, but the current offerings are either expensive, poor quality or require nails or adhesive for installation, which is against most dorms' policies.  

'Alternative' whiteboard solutions such as the whiteyboard tend to peal off and be hard to erase.  Going to Loews or Home Depot, a properly-sized white-board may cost as much as $150.

Here's the opportunity: A mass-produced, reasonably-sized (3' by 4' or so) whiteboard/markers/eraser combination sold to college freshmen during move-in.  The whiteboard comes with adhesive materials that have been proven to do no damage to the walls they are stuck on. 

4.  "Focus" headphones

Consider noise-cancelling headphones that only have one button: to turn on the white noise.  

As headphones meant to be worn when trying to focus on a particular task, these would serve two purposes:

  - first, they eliminate external auditory interference
  - second, the design is distinctive (perhaps a big 'FOCUS' or an exclamation mark on the back) and makes it clear to others in the room that the person wearing the headphones is not to be disturbed; they are deeply focused on something important.

5. "Who's around" roommate checkin board

If you knew which of your house-mates was around at any given point, you'd know if anybody was up for dinner or perhaps whether you and your new friend would need to be discreet as you made your way to your room.  

A simple board with 5-10 switches, marked 'Home' and 'Away' mounted on the back of the front door gives house-mates a simple way to communicate to their neighbors' current status. The convenient location makes updating painless and near-automatic as roommates take of their jackets or shoes.  A small attached whiteboard lets roommates be more particular about their status (IE, "do not disurb, midterm tomorrow").

What do you think? Are any of these worth pursuing?

I've been using tungle.me for about a year now. The service lets users post their availability publicly (tungle.me/Alexey), letting users send emails like "Sure, let's get coffee next week. My availability's at tungle.me/Alexey; let me know what works for you."  Availability data is taken from users' Google calendars; if you're like me and meticulously schedule your day on GCal, the remaining 'empty' slots coincide quite reasonably with times I'm available. Visitors to a tungle.me page also have the option to schedule a meeting directly on the page.

Review
All in all, the service is great. It solves so many 2-way scheduling problems that I ended up having my tungle.me page as the only thing in my email signature. The site still has a number of kinks - schedulers are forced to offer multiple meeting times, for example, and a failure to synchronize with GCal will result in me being listed as 'available' when I'm not).  A couple of extra features would be nice, too; for example, tungle.me/Alexey/30-minutes-next-week should be a link I can send somebody that would limit potential meeting times to available 30-minute blocks next week. Still, tungle.me solves a time-consuming pain point, so I use it.

It's worth noting that what I've seen of the site's growth has been entirely viral. The company is based in Montreal; I found out about it when I got a Skype meeting invite through tungle.me.  Since then, several friends have adopted the service.  Tungle.me is viral.

Reaction
Mostly, people tend to react positively or neutrally to my sending out tungle.me links.  Less tech-savvy users tend to continue to schedule meetings over email, (How about 6PM on Thursday? Your tungle.me says you're free) though I do get the occasional tungle-direct invite as well.  

A more interesting (and rarer) response, however, has been to refuse to use the service and instead insist on coordinating schedules over email.  Partly, this could be a direct Luddite response, a la "I don't trust new apps," (not that any of a user's data is being accessed or used).  A more common issue is that of social status. Saying "You, go pick a meeting time for us" can be interpreted in two ways: either as "I really want to meet with you, pick any time you're free," or "Go talk to my digital secretary about scheduling a meeting; I don't deal with little things like that personally."  

The second interpretation pops up in sitautions when you try to ask somebody for a meeting and then ask them to schedule it.  The gut reaction is often "wait, you want this meeting - why am I doing the scheduling?"  Rationally, using tungle.me is time-saving for both parties, but it's hard to explain that to somebody you're working your ass off trying to get a meeting with.  Social dynamics are hard; norms may adjust to be more tungle.me friendly in the future, or tungle.me might find ways to make it look like the initiative is being taken by the meeting proposer.

Conclusion
tungle.me is well positioned amongst early adopters, viral, and useful.  As it expands beyond early adopters, I think it's going to be part of the future of scheduling.

What do you think - am I being a douche by asking contacts to check out my availability on tungle.me instead of taking the time to write it in an email?

Note: Multi-person meeting schedulers (scheduleonce/when2meet/doodle) are interesting too and probably deserve a post of their own. 

If you look at my LinkedIn account, it would seem like I'm not a particularly active user; I've only got 79 74 connections and no picture.  Here's the thing: I'm not sure if I'm using it right.

My LinkedIn 'friending' policy is simple: I'll accept a connection if the person offering it is somebody who I would feel comfortable recommending if somebody asked "hey, do you know any good ____?"  Unless I've worked with somebody, am personally friends with them, or have had the kind of conversation where I can sort of smell competence, I probably am not comfortable being a LinkedIn connection of theirs. 

There's a reasonably good chance that I'm wrong. My friend Yujin, an MBA who now does bizdev for Venture Capital, says I should be friending most business connections I make and that this is the norm for LinkedIn.  As a result, Yujin's got 500+ connections and is the ultimate connector.  And he rocks it.  Still, I feel uncomfortable with the idea of being a connection (and, effectively, agreeing to be a reference for) somebody who I don't yet trust.

LinkedIn seems to at least somewhat agree with me on this; when I try to add a new contact, it warns me to add only 'people you know well and who know you.'  And yet, I've had a number of (reasonably respectable) random people add me as a LinkedIn connection as a way to get an introduction.  There's a reasonable chance that this is because they can't find my email address and LinkedIn tries to make money by offering 'direct contact via inMail' as a premium feature.  

One solution to the whole friending strong versus weak ties (which, esp. when compared to Facebook's or Twitter's, probably deserves its own post) is LinkedIn's endorsements feature.  If you really want to show that you trust somebody, endorse them by writing a positive recommendation.  Still, I can't bring myself to 'accept' people I would not (yet) comfortable hiring or working for.  

It would be nice to have a social rolodex where I can can add anybody I've ever met, without any implied friendship or any fears of references or privacy.  This is almost what Twitter is, except that I'm not particularly interested in what random people I've met once have had for lunch.  What I would (ideally) like is a social, digital rolodex, sorted by time and (perhaps) with some sort of tagging features, so I can mark people by the things we share in common.

Perhaps I'm just old-fashioned.  What are your LinkedIn 'connection' policies?

I gave a talk at BarCamp Philly a couple of months back about best practices in hiring technical (mostly CS) interns from Penn. I've since distilled the talk into bitesize pieces and plan to publish its remnants here, starting with the Who and the Where.  If we haven't met, I'm a CS Junior @ Penn.

The Problem

You've figured that, for whatever reason, you want to recruit some Engineering/CS talent from Penn to work with you on something, either in an internship or a partnership capacity. That's cool. We'll re-examine the assumption that a Penn CS student is who you really need in a later post, but let's continue on for now.

Unless you come from Penn Engineering and/or have a CS background, though, it's not entirely clear what you should be doing to reach out. Here's what you need to know:

Who we are

As everywhere, the culture varies and stereotypes aren't particularly welcome. We've got frats, we've got gamers, we've got game makers, we've got the kind of science and technology geeks who decided it might be fun to launch a blimp, we've got all kinds. We're engineers. It's a good mix. 

In terms of your competition, here's a rough estimate as to the type of work students are looking for. Google doesn't just mean Google in this case, it means large, successful engineering-driven tech company.

Pixar's representation is a result of the Digital Media Design program. DMD students are known for (at least to me) as being able to draw and handle graphics, while at the same time being able to out-code you any day. They're kind of impressive.

The Goldman Sachs/financial side of the pie chart is a result of Wharton School/New York influence. We have a disproportionally large amount of Wharton dual-degree/M&T students studying things like Finance & CS, who end up going to work for investment banks and hedge funds. Since a lot of these financial companies are on campus, they end up recruiting from CS reasonably heavily. I'm doing my best to withhold judgement here.

Finally, the 'start my own company' group is a small but growing one, bolstered by recent successes like Invite Media and Milo, two recent Penn CS start-ups. We're growing. This is a good time to be at Penn.

In appealing to Penn CS students, try to figure out whether you fit into any of these categories reasonably well, since these are going to affect who and how you pitch your proposed employment.

How to reach us

From broad to personal, here's a list of ways to reach out to students studying CS@Penn:

• PennLink is Penn's official on-campus recruiting website. I can't vouch for it, though: my only experience with PennLink was when looking for a summer internship my Sophomore year. Back then, most of the jobs available seemed generic (consulting, etc) and the technical jobs were mainly by large corporations that I wasn't interested in. I'm not sure how well other CS majors have fared on PennLink, though.
• Penn Student Design is an internal 'web design' guild run largely out of DMD. If you're looking to have a freelancer-type arrangement help you make your website look impressive, contacting PSD makes a lot of sense.
• Jackie Caliman is the Associate Director for Advising of the undergraduate CS department. Let me digress and say that there are no words to describe the sheer awesomeness that is Jackie.  If every organization has a person behind the scenes keeping the whole thing together; for us, that's Jackie Calman.  
  The reason that's relevant is because Jackie sends out CS list-serv emails on behalf of potential employers. Most of the interesting job opportunities I end up seeing come from that list-serv; I'd recommend reaching out to Jackie to see if she'll forward your email on.  That said, we get a lot of reasonably painful-to-read emails. I'll discuss exactly how to put together a good pitch to a CS student in a later post.
• PennApps.com [shameless plug] is a twice-yearly, student-run weekend-long hackathon that brings out a lot of the top 'I can make something really fast' hacker-types out. If you can afford it, (IE, if you're funded) you should sponsor - we do our best to help sponsors meet and recruit top participants for internships. If not, you should show up to demo session and see what people are up to.
• PennLaunch is a sort of internal LinkedIn for Penn, focusing on specific projects people are working on. Run by the Weiss Tech House, the site hasn't reached it's potential yet (IE, not enough engineers are on it), but it's getting there.
• Penn StartupConnect and Startup Speed Dating are twice-yearly events run by Josh Wais and Gayle Laakhman, respectively. The two use slightly different formats, but the idea is the same: get people from the business/tech side of things into the same room and let them take it from there. Watch out for these if you're in the Philly area.
• Professors are often worth meeting with, especially if you've figured out what particular field (Machine Learning, Computer Vision, NLP, etc) you need talent in.  If they like you, they may just introduce you to some of their top students.
• Last, there's always old-school networking. Ask around - see who you know who can introduce you to somebody who is part of the community. [Another shameless plug] I'll typically have lunch with anybody interesting that offers to the detriment of work that needs to be done. 

That's +/- it. Let me know if you have any questions and if there's anything in particular I should address in future posts.

Professor Jason Dana and I have been experimenting with Cheating and Turker Quality on Mechanical Turk. If you haven't yet, check out Part 1. Thanks for everybody's feedback so far - please keep it coming.

Recap

When we left off, we had just offered workers on Mechanical Turk the job of flipping a coin, paying them 4 cents for a flip of heads and 2 cents for tails. We wanted to measure whether and how much particular groups of Turkers, bucketed by their quality score, would cheat when given the chance to do so.  

Though our initial results seemed to suggest a positive relationship between having a high quality score and not cheating, the amount of data collected was less than desired and did not have the numbers required for statistical significance.

Experiment Two

Realizing the difficulty of attracting top Turkers to a task that offered only two cents, we decided to up the ante and make two changes: first, we renamed the task to a more attractive "One quick question. Should take ~15 seconds."  Second, we raised the price of heads and tails to 10c and 5c, respectively.  Once again, we asked 50 Turkers in each of our quality groups to flip a coin, for a total of 300 coin-flips.

Results

Here's what we got.  

Note: Error bars are at a 95% confidence interval.

This time around, all 300 HITs (tasks) we put out were done in a matter of days. The data, however, became less clear: sure, we expected the <90% and 94-90% groups to cheat a ton (as they did), but what was the 100% group, the 'cream of the crop' doing by taking advantage of our trust and cheating as much as the lowest group, <90%?  

Discussion

This bothered us for a while.  Who are these 100%-ers, after all? This is the group that can do no wrong, the group that makes less than 1 error in 100. How could they have betrayed our trust, especially after we offered them more money? 

Melika Cavagnaro-Wong, a friend from Wharton, provided the key insight here: 100%-ers aren't necessarily the group that can do no wrong. They're just the group that never gets caught.

Hypothesis

I imagine a contingent of Turkers who have optimized their workflow to a tee. It's not easy to make a solid hourly wage from Turking, so one has to maximize productivity. Tasks below a certain financial payout or that take too long to do are not an option. HITs where quality can be ensured (identifying objects in images, transcribing audio) are only worthwhile if they pay well. HITs that can be easily gamed, however (multiple-choice surveys, coin-flips) are ripe for cheating - why not?

In an extreme state of the world, I imagine a cabal of Turkers somewhere, collaborating to maximize their effective hourly wage. Members would take turns looking at new tasks and figuring out (or even using software to measure) the expected hourly wage of a particular task. Other members in the group would then be sent links to the 'juiciest' tasks, and some sort of queue system would be used to manage what a particular cabal member's next task ought to be.  Note: we're looking into whether we can trace any evidence of something like this and will post about them at a later point.

Why, then did this hyper-efficient cabal not invade our 2c/4c experiment? Quite simply, the 2 cents advertised (the other 2c came as a bonus) initially likely flew well below their radar as a task not worth any time at all. Instead, the 19 people who did come to us from the 100% group are more likely to be the 'part-timers' - people who answered Panos Ipeirotis' 'Why do you Turk' survey with either "it's fun" or "it's rewarding."  This group is not financially motivated and less likely to cheat.

These altruistic Turkers are a minority, however; once money comes into play, they get Crowded In by the 100% optimizers.  

Crowding In

 In behavioral economics, crowding in is the idea that paying too much for a task may get the wrong kind of people to do it. A classic example of crowding in is paying for blood donations, outlawed in the US and most of the rest of the world for several decades now. The problem, as Richard Titmuss described in The Gift Relationship: From Human Blood to Social Policy, is that offering cash for blood gets the exact wrong kind of blood donor: the type that could really go for some cash right now and therefore may not have the cleanest blood available.  

Similarly, as we offer increasingly larger enticements to participate in the coin flip experiment, we seem to be crowding the 'doing this for fun' crowd out in favor of the 'optimizer' crowd. The effect should be particularly evident in the 100% group, where both a lot of altruists and a lot of optimizers are likely to end up, altruists because they do good work and optimizers because it pays to be qualified for restrictive tasks.

Experiment

Luckily, this turned out to be a reasonably simple thing to test. Taking the 100%-ers as our experiment and 95-97% as our control group, we offered the same coin-flip experiment to 50 participants in each group and altering the payment for tails/heads to, one after the other, 10c/15c and 3c/8c. We kept the bonus at 5 cents and altering only the original offer, since the base payment is the only number Turkers can see before accepting the HIT.

Results

Note: Error bars are at a 95% confidence interval.

 From our experiment, it looks like while offering more money leads to more cheating for the 100% group, cheating actually goes down for the 95-97% control group. This fits with our hypothesis: in the 95-97% group, adding more money disincentives cheating - 5 cents for cheating looks less enticing if I've already received 10 cents and more enticing if I've only received 3. Dishonesty can be bought, but only at a reasonable multiplier to the base reward.  

In the 100% group, however, the opposite occurs: the more money is offered, the more interesting the task becomes to optimizers, and optimizers cheat whenever they can get away with it.  

The results are not quite statistically significant, as the error bars illustrate, but they tell a reasonably compelling story nonetheless. 

Do you agree with our hypothesis?  What other, alternate explanations might exist for these results?

Next Steps

We collected additional data about the Turkers as we conducted our experiment. Here's some of the analysis I intend for Part 3:

• Cheating by Time Taken: Can we predict whether a Turker really flipped a coin or not by looking at how long the assignment took them?
• Cabal Trends: Can we identify any collusion amongst Turkers?  Assuming Turkers share tasks, are there any patterns of heads-heads-heads-heads... in our data within a fairly short time span?
• National Trends: Most Turkers (>90%, in our case) are either in the US or in India. Do Americans or Indians cheat more? Is either group more likely to be 100%-ers? Are Americans less likely to accept low-paying tasks? We started tracking IPs only by the time we ran the 3c/8c and 10c/15c groups, but even that subset of data points remain interesting.

Any ideas for other interesting analysis I should run?

Over the past semester, I participated in an Independent Study in Behavioral Economics with Professor Jason Dana.  Here's what we've been up to:

Mechanical Turk is Amazon's 'artificial artificial intelligence' service. Named after a fake chess-playing machine in the late 17th-18th century, According to Amazon, MTurk is a

marketplace for work that requires human intelligence. The Mechanical Turk web service enables companies to programmatically access this marketplace and a diverse, on-demand workforce. Developers can leverage this service to build human intelligence directly into their applications

As Jeff Atwood explains,

It's a service that attempts to match people to small, bite-size units of work that are unsuitable for machines.

For example: You have a list of thousands websites and want to know which ones are appear to be well-designed. Algorithms to quantify taste do not yet (sadly) exist; instead, either look through the websites yourself, or offer the task to Mechanical Turk. Turkers, as the workers are called, are then paid 5 cents (or however much you offer) to rate each website. Hundreds of people can work on your classification task in parralel, saving time and money.

Common uses of Mechanical Turk include transcribing audio, identifying photos, or answering opinion surveys.

The Cheating Problem

Without oversight, what prevents Turkers from voting randomly? For objective tasks, you could manually go over each result yourself, but this would be exteremely time-intensive and defeat the purpose. For subjective tasks, even that wouldn't be possible - who knows if the Turker's choice of 3/10 for some website was his actual opinion or a random choice?

There are a couple of approaches that work here. You could try to get multiple Turkers to do each task and make sure they agree on the answers.  You could do part of the work yourself, (set a gold standard) and verify Turker quality by how well they do on the tasks to which you now know the right answers. Finally, you can restrict your Turker employee base to a highly-qualified one, limiting your employee pool to those who have done good work before.  As a side note, companies like CrowdFlower try to restrict and manage for high-quality workers on your behalf; if you're willing to pay more for your automated tasks, I've heard good things about them.

Amazon measures this 'done good work before' metric by looking at the Turker's HIT Approval Rate - the % of tasks that this worker has done in the past that were subsequently accepted by the employer. Limiting your workers to 95%+ is a standard way of trying to obtain only high-quality responses.

The Research Question

The question, then, is whether limiting the Turkers to those with a high acceptance rate is an effective way of making sure they don't cheat.  We were also wondering where the cutoff for cheaters was and whether the amount of money offered for the task would affect the amount of cheating.

The Setup

Our experiment is as simple as possible:

The idea is based on an experiment Prof. Dana has run at Solomon Behavioral Labs at Penn as well as abroad [that we should probably link to/cite here].  We can't tell if any particular individual is cheating - perhaps they happened to flip heads - but in the aggregate, if we ask 50 homogenous Turkers to flip a coin and see how many heads we get, 50 heads indicates that the Turkers are a dishonest bunch, while 25 heads and 25 tails would indicate a fair and friendly group of turkers.

We offered the same task to 50 turkers in one of several groups, varying by HIT Approval Rate. An informal survey (IE, we asked one of Prof. Dana's grad students) suggested that cutoffs of <89%, 90-94%, 95-97%, 98-99% and 100% would be reasonable. We also offered the task to a group of Turk newbies (filtered by the fact that they had less than 20 tasks completed under their belt).

Offering 2c for tails and 4c for heads, we hoped to see how rampant cheating for subjective tasks was amongst various groups of accomplishment. 

The ResultsThe data did not dissapoint. Excluding the 95-97% anomaly, the trend was clear: the better your Turkers, the more honest (by and large) they would be when offered subjective tasks where they could cheat without being detected.

Since this was our first attempt at Mechanical Turk, though, we did not do as good of a job with the price offered or the marketing of the task (we named it 'Project Random'). As a result, we got only 158 participants (out of a possible 300), and only 19 100%-ers.  Clearly, the price offered would have to go up. 

How do you think offering more money affected the cheating chart? Should cheating go up or down, as a whole, if we offer 5c/10c instead of 2c/4c? Should any groups be more or less affected than average by an increased incentive to cheat?

Update: Part 2 is available here.

Quick heads-up, in case anybody else runs into this problem.

Background:

I've been working with passing an ExternalQuestion to MechanicalTurk, and have learned (the hard way) that the 'ExternalURL' component, set up as a "xs:anyURI" in the MTurk AWS schema, does not allow ampersands '&' except if escaped via '&amp;'. 

That was not at all obvious. The AWS exception gives is:

<CreateHITResponse>
  <OperationRequest>
    <RequestId>...</RequestId>
  </OperationRequest>
  <HIT>
    <Request>
      <IsValid>False</IsValid>
      <Errors>
        <Error>
          <Code>AWS.MechanicalTurk.XMLParseError</Code>
          <Message>There was an error parsing the XML question or answer data in your request.  Please make sure the data is well-formed and validates against the appropriate schema. (1291006584155 s)</Message>
        </Error>
      </Errors>
    </Request>
  </HIT>/
</CreateHITResponse>

Solution: 

Replace any instance of & in the ExternalQuestion URI (IE, www.yoursite.com/mturk/a.php?foo=true&bar=false) with &amp; (IE, www.yoursite.com/mturk/a.php?foo=true&amp;bar=false).

That'll fix it.

Reference: 

ebay developer docs (strangely enough), External Question documentation.

TL; DR: want to auto-generate .h files from .c files? Type this into vim.

C sucks. [Disclaimer: OK, I don't like C; I'm a python/functional languages guy. You may love it. Whatever.]

There's lots of little annoying things about C; memory management, using #ifdefs for header file declarations, manually written header files, etc. The good news is, I've half-solved the last issue.  

Say you have a simple main file, as follows

int main(int argc, char ** argv) {
  char* str = malloc(sizeof(char*) * 3);
  str[0] = getFirstChar();
  str[1] = 'F';
  str[2] = '\0';
  printf("%s", str);
  free(str);
  return 0;
}

char getFirstChar() {
  return 'A';
}

Dead-simple. Unfortunately, you get the following issue when trying to compile:

main.c:11: error: conflicting types for ‘getFirstChar’
main.c:3: note: previous implicit declaration of ‘getFirstChar’ was here

Here's why this happens: the C compiler parses your c file once. The first time it sees getFirstChar, it realizes that it hasn't seen a method declaration for it yet, so it creates an implicit one. Unfortunately, an implicit declaration, or stub, will always assume a return type of int, while the actual type is a char. So, type mismatch.

There are a couple of ways to solve this problem:

1. Put getFirstChar above of main. This kind of works, but now you've got to order your functions based on some partial order you can't control. If you've got an instance of two functions calling one another in some proto-co-recursive way, this won't work at all. In general, less flexibility than you'd like.
2. Declare the method headers at the top of the file/create a header file

   int main(int argc, char** argv);
   char getFirstChar(); 
   ...
   #include "main.h"

   This it the 'proper' way to solve the problem, but now you've got a header file you've got to keep current. If you're the kind of person to plan all of your code out before you write it, you're paying a one-time cost to create a header file. If you're making updates, however, or if you're like me and you figure out what methods you should have as you go along, this means you're updating the header files every time you edit a method name, just to freaking compile, all to solve a problem other languages don't even have.

The solution

In its most basic iteration, a header file is just your method declarations w/ semicolons instead of open braces. It shouldn't be that hard to just auto-generate the header file whenever you make a difference, or whenever you compile. So that's what I started doing. I'm a vim guy. With a bit of research and poking around, here's a quick command you can run in vim to generate a simple .h file from a given .c file:

:%s/^\(\w.*{\t*$\)\@!.*\n//
then:
:%s/ {/;

[Disclaimer: Do not use this in its exact form for a serious project. Header files are a bit more complicated than the version we're dealing with.  The current proposal is best suited for homework assignments or quick one-off projects]

What this does: The commands above remove all lines that don't look like a method declaration, then swaps open braces for semicolons. Note that it assumes that you don't indent your method declarations and that you inline the opening brace of function declarations. To use the commands, just copy the .c file to a .h, open the .h and run those commands.

Next Steps

I don't have to write any more C for another week or so, but I think the following steps make sense for taking .h file generation to the next level:

1. Rewrite as shell or python script.  Switching from vim commands to python is probably going to add some flexibility.
2. Incorporate the script directly into a Makefile.  In this scenario, make will depend on header files being re-generated, and only then call GCC.
3. Include some of the other stuff .h files typically include This current approach makes the assumption that all relevant comments, #includes, structs and typedefs in your program belong in the .c file exclusively. Typically, at least some of those belongs in .h instead. A future version would potentially modify ensure that previous .h files are not overridden but instead amended. 

Hopefully the commands will come in handy to others as spoiled by HLL as me, who can't believe that C doesn't already to these things for you.

Thoughts/feedback?

This is going to be the personal/professional blog of Alexey Komissarouk (that'd be me), where I'm going to write about my particular interests: the hazy intersection between Web 2.0y-things, Data Mining, the Social Graph, Behavioral Econ, Product and UX Design, Data Visualization, Tech@Penn, and really any other buzzwords that will feel appropriate. I'm planning to do a reasonbly-sized post at least weekly, and potentially throw in some shorter stuff here and there.

The point is, sometimes I have these thoughts that aren't completely idiotic. It's about damn time I aggregate and centralize them, to feed the google, etc.

I leave you with an interview I did with Soleio (a Designer with Facebook and overall awesome guy) for PennApps 2010.