Alexey needs a web presence

Statistical Significance on a Shoestring Budget

2023-09-11T08:02:41-07:00

Many startups experience a chicken-and-egg problem with growth: they want to run experiments to gain more volume, but lack the volume for experiments to be practical.

This guide helps companies determine if (and how) they could staff a Growth team to start running experiments. First, we’ll diagnose what is achievable with the amount of traffic currently available. Then, we’ll dig into what techniques might be available to increase experimental power.

As any proper guide ought to, this one includes a handy flowchart.

Part 1: Do we have the numbers?

Consider an imaginary startup in turn considering funding a checkout optimization team.

Being well acquainted with power analysis, this startup gets its Minimal Detectable Effect - IE, how big of a swing would it need to.

Plugging their numbers into a swing size calculator, they learn that nothing less than a 20% win be detectable today.

Even 10% is a high bar to cross for winning experiments.

Gut Check Especially if you’re off by quite a bit, this is a chance to take a step back and ask whether the company has reached growth scale or not. It could be that there are plenty of obvious 0-1 tactics left. Not everything has to be an experiment.

In cases where experimentation remains the right choice, let’s find ways to adjust your experiment designs to be able to detect a 10% winner within a reasonable timeframe.

Part 2: Boosters

Things to try if you need to get just a little bit closer to get to stat-sig:

Bigger Bets: combine ideas together, merging by theme

The first thing to try is combining certain ideas with a common theme together. For example, if you believe emphasizing your transparent pricing will help conversion and are considering experiments to display your transparent pricing prominently on your homepage, during checkout, and in your cart abandonment emails.

Instead of running 3 experiments which might (for example) each move conversion by a bit, run them as a single “emphasize transparent pricing everywhere” mega-experiment so it has a better shot to hit the 10% detectable threshold you need.

The trade-off is reduced learning quality. When productionizing a batched win, it’s harder to tell which part of the change was actually effective. In the near term, this is tolerable - when the company gets to a larger scale and you revisit this theme, you can always tease out the underlying causes through follow-up experiments.

Best Foot Forward: Use fewer variants, A/B/C/D become A/B

You need a certain number of visitors to both your “winning variant” and “control” to determine the result. Every variant you add reduces the oxygen flow to your winning variant.

If you’re tight on traffic, stick to two variants.

The trade-off is, **this reduces your win rate, since you’re not getting to try as many options.

Run in Parallel: A/B/C/D becomes A/B, A/C, and A/D

We know by now that combining ideas together gives them the best shot at being sufficiently big winners. Some ideas, however, are dangerous enough to merit greater care.

Consider bodybuilding. You are probably fine combining “drink milk,” “eat raw eggs,” and “get good sleep” all at once, since these are relatively common approaches. However, if you decide to start injecting experimental supplements, you probably want to go one supplement at a time. If the side effects end up harmful, you want to be crystal clear on what is causing them.

The same is true for particularly sensitive experiments. Consider a test around “combatting high price perception.” **Various alternatives include a value-focused redesign of the pricing page, a free trial, and a price drop. **Since the latter two may be net-harmful to revenue, we should test them in isolation carefully.

Unlike with bodybuilding, testing in isolation does not require slowing down. Using modern experiment frameworks, all 3 of ideas can be safely tested at once, using parallel A/B tests (see chart).

Even better, as a side effect, you also gain directional evidence about how the ideas interact when they work together (IE, the free trial seems to work much better with the new redesign).

The trade-off is, running multiple experiments on the same surface area increases the burden on both engineering and analytics. For engineering, more complexity means more tests to reduce the potential for edge cases. For analytics, simultaneous experiments provide an extra require to inspect experiment interactions to avoid drawing false conclusions. When bottlenecked on experiment volume (versus eng or analytics throughput) this can be a worthwhile tradeoff.

[hat-tip to Taylor Adams]

The place that has the most experimental power will generally be at the start of your checkout flow: it is seen by 100% of eventual purchasers, and converts relatively well. Your homepage is probably also a high-throughput surface area, but some customers may skip it and convert straight from other landing pages.

To get more power for top of funnel experiments, you can either (a) avoid custom landing pages and send almost all your traffic to the homepage or (b) share reusable components between your homepage and landing pages, and run experiments within those shareable components.

The trade-off of this approach constraints the amount of flexibility you can have on your other landing pages. Early on, it can be quite valuable to avoid constraining landing page formats, since that team needs to be taking its own big swings.

Run tests for longer: 7 days becomes 2-3 weeks

If you have more traffic, you get a larger sample size, which means you can detect smaller wins easier.

The trade-off is the likelihood you’ll get to see the experiment through. Especially at earlier stage companies, I rarely see the discipline to actually leave an experiment running longer than a couple of weeks. Inevitably, an executive will pop in and demand an update. “Trending positive?” they’ll say, “Great, let’s just ship it, it’s fine.” And it is fine, except now you’ve committed the cardinal sin of peeking, your likelihood of a false positive has gone up, and you have not truly “learned” anything that will help your experiment roadmap.

If you often find yourself shipping tests earlier than planned, consider switching to a non-frequentist (fixed-sample) methodology, such as Bayesian or Sequential statistics.

Get Comfortable with False Positives: p<0.05 becomes p<0.2

Another tolerable trade-off: in a world where a false positive is harmless, get comfortable setting your Type 1 Error tolerance (IE, how often can I live with a false positive) from its traditional a=0.05 (a 5% false positive) as high as a=.2 (a 20% false positive rate)

The trade-off is, you shouldn’t do this for risky or significant changes, such as a new pricing strategy. Also, realize that your ability to trust your learnings from experiments is decreased, since there’s a greater chance your “insights” are now coming from noise and not reality.

Buy Traffic

[hat-tip to Taylor Adams]

If the budget is available, you can always ask the paid marketing team to increase their spend during your experiment. A quick traffic boost can get you the numbers you need.

The trade-off is, newly-acquired prospecting paid traffic tends to be lower intent than your average visitor, so expect some conversion degradation (which may, in turn, make getting to stat-sig harder). Also, there’s probably a reason the paid marketing hasn’t increased their budget yet: the newly-acquired traffic is unlikely to be cost-efficient, and will likely burn money, so try not to pull this card too often.

Part 3: Desperate Times

When you’re an order of magnitude (>2x) away from stat-sig, there’s still a few (more aggressive) things to try:

Target a Proxy Metric

At Opendoor, our team’s job was to optimize conversion for people selling us their houses. However, a house sale actually closing took months and was not a common event, especially compared to a SAAS or eCommerce setup. Instead, we found a number of proxy metrics (offer viewed, etc) that we could target instead.

The trade-off is the new layer of indirection. Without being careful, it’s easy to get caught up in moving the proxy in a way that doesn’t help with your actual goal. For example, at Opendoor, shortening the purchase flow would result in more offers viewed, but fewer purchases at the end (since the offers would be less accurate).

To ensure the proxy metric doesn’t steer you astray, you can:

Find or create higher-signal proxy metrics, such as a lead score model that can more accurately predict eventual conversion than merely the event itself taking place.
Keep an eye on the impact your experiments are having on the true metric at least quarterly.

Run your Tests on the Paid Layer

[Hat-tip to Julian - I can’t for the life of me find the original quote, but here’s a good guide]

If you want to experiment with several headlines or images on your landing pages but don’t have enough traffic, you can test those very same headlines or images on paid marketing ads. The ones that perform best at the paid traffic level are reasonable candidates to do well on your marketing page.

The trade-off is that **this approach is limited in which parts of your product journey you can test.

Go Qualitative with Surveys, Paid Feedback and Session Recording

If you want to gain intuition for what users want - just ask them, or look for yourself!

There are several ways to get qualitative feedback about variants in your conversion journey:

1. Use a tool like hotjar.com

to ask a fraction of customers on the website to take a quick survey about their experience.

However, customers willing to do surveys are not always representative of your potential users.

2. Pay testers

on sites like UserTesting to go through your site (or even just designs iterations) and offer their feedback/see where they get stuck.

However, if you’re targeting wealthier customers or business purchasers, you may not get representative feedback.

3. Use screen recording tools

like Sprig or FullStory and personally watch the experience of tens of customers in your experimental variants.

However, it’s easy to get fixated on a specific issue that may not be representative or affect many customers.

Ideally, many of these approaches are often used during design, as a precursor to running an A/B test, but in a pinch, they can be used to in lieu of the quantitative tests.

YOLO - Just Make the Change

Ultimately, the simplest thing you can always do is just go ahead and make whatever change it is you believe in. So long as you are right often enough, you should start to see conversion starting to tick up over time.

This approach also saves a decent amount of engineering effort, since you no longer need to spend eng effort on supporting more than one version of your site or product.

The trade-off is that without the precision A/B testing, it’s that much harder to know which of your efforts are actually working, and which are neutral-to-harmful. Working pre-post puts you back in the old days of “half of my marketing efforts are wasted, but I don’t know which half.” At the end of the day, favoring conviction and best practices over experimentation is a reasonable approach, especially early on in a company’s lifetime.

There's no such thing as Organic Traffic

2023-04-04T09:00:29-07:00

From a recent investor update:

…and 40% of our purchases in Q1 came from organic traffic

I, uhh, don’t believe you.

A purchase from organic traffic is:

the customer had the problem your product solves
they googled
they clicked on your website from the organic search results
and then bought it.

I too would rather live in a world where this was still a thing. But this was probably not what happened.

What’s the big deal, you pedant?

One-half of the money I spend for advertising is wasted, but I have never been able to decide which half

- John Wanamaker, Department Store Magnate, 1919ish

John Wanamaker, a Department store magnate, said this in 1919 or so. So that’s literally a century year old excuse. You can do better.

The customer acquisition team’s job is to double down on what works. Somebody on your team deserves a bigger budget - knowing who is part of the job.

OK but for real, these customers did come from organic search

Sure, but that is only a superficial explanation of their “source.” What motivated them to search? Here’s an (in-exhaustive) decision tree of possibilities and initiatives deserving credit.

At the point they googled for it, had they heard of your product earlier?
- Yes - give credit to how they originally heard about it
  - Did they hear/see an ad? ➡️ Paid ad channel
  - Was it from a friend/colleague? ➡️ Word of mouth
  - From an existing user? ➡️ Referral
- No - credit should go to your SEO & brand efforts. Were they searching for…
  - Your company name explicitly (ie, hotels.com) ➡️ brand effort for domain
  - The problem you solve (keyword) ➡️ SEO / content team.

Fixing “Organic Search”

First, unless you actually rank for your category’s generic domain name, re-label the “organic” traffic as “unattributed.”

At that point, there are a few ways to allocate the unattributed conversions:

Simplest: spread evenly across known channels

Let’s say your purchases come from 40% paid social, 10% referrals, and 20% SEM. You have 30% left unattributed, so allocate these proportionally.

Note: I am terrified of this approach because obviously different channels can have different amounts of “search later” halo effects, but at least it is less wrong than “Organic” and it can be done entirely post-facto.

Slightly better: Incorporate How did you hear about us? (HDYHAU)

Once customers have purchased, ask them how they first heard about you, via a HDYHAU survey.

Now, look, many customers will skip the survey and others just won’t remember, but the answers you do get from the unattributed crowd are still worth applying to your estimates. It’ll help realize things like “oh, most people who are unattributed are actually coming from Instagram - as are a bunch of people we thought were referrals” and adjust your focus accordingly.

Fancy: Marketing Mix Modeling

At some point you get big and successful enough that you hire a fancy full-time marketing analytics leader, who will understand this subject way better than either you or me.

They’ll bring in tactics like incrementality testing, where Google or Meta will start running internal tests for you where they exclude a handful of their userbase from your ads and show you the effect it has. Or you’ll do something simpler like turn off specific channels in specific countries or US states and see how much their purchases fall. They’ll talk you through whether “online advertising is a lie” and help figure out how proportionally distribute credit for any sale across multiple channels, first touch vs last touch, and other fun things of that nature.

You will eventually reach a scale where this investment will be justified. Until then, just realize there’s (probably) no such thing as organic traffic.

PS. Only getting harder over time

Between the ever-increasing popularity of ad-blockers, common pattern of “see it on mobile, buy it on desktop” cross-device purchase behavior, iOS14 and government-driven private regulations, the % of your purchases that are unattributed will only go up over time. If scaling up customer acquisition is important to you, get it right.

Hamtips, or why I still run the Technical Phone Screen as the Hiring Manager

2021-09-15T16:51:08-07:00

Caveat: Yes, yes, almost everything about the interviewing / recruiting process is broken. Sometimes though, you just have to play the hand you’re dealt and settle for minor improvements.

The 75-minute HMTPS is my proposed minor improvement.

Hat tip to The Oatmeal

What is the HMTPS

It stands for “Hiring Manager Technical Phone Screen.” Since you asked, I’ve been pronouncing it “ham-tips.” It’s the call a candidate will have after their RPS (Recruiter Phone Screen) but before their onsite.

This combines two calls - the Technical Phone Screen (TPS), which is a coding exercise, and usually happens before the onsite, and the HMS call, which is a call with the Hiring Manager (your would-be manager), which I’ve seen done before an onsite, or after, or not at all.

So I combine these into one. It takes 75 minutes.

Why combine the two interviews?

An ideal interview loop has as few steps as necessary and gets to a decision ASAP. Combine these two steps to shorten intro-to-offer by ~1 week and reduce candidate drop-off by 5-10%.

It’s also a lot less work for recruiters playing scheduling battleship¹.

Finally, Hiring Managers will, on average, be better at selling working at the company - it’s kind of their job.

Why 75 minutes?

We’re combining a 30-minute call and a 60-minute call, and combining the 15-minute Q&A at the end of each into one.

TPS (60m)

5m Intros
45m We write some code in Coderpad together
10m Ask me Anything

HM call (30m)

5m Intros
10m Dig into relevant experience & what candidate wants from next job
15m AMA time.

HMTPS (75m)

5m Intros
15m Dig into relevant experience & what candidate wants from next job
30m Coderpad
15m AMA time.
10m buffer time (inevitably one of these will go long in an interesting way)

I’m also more comfortable shortening the ~50 minute technical question into 30 minutes because (a) I’m pretty calibrated on my question, having run it 200+ times at this point, and so can get most of the signal I’m looking for within the first 30 minutes.

I’ve tried doing this call in 60 minutes and it ends up feeling pretty rushed; not to say somebody else couldn’t pull that off, but I’ve appreciated the bit of space. Also, since most candidates don’t schedule in 15-minute increments, we can always go a little long (up to the 90 minute mark) if we need to.

Why is this good for the Hiring Manager?

First, it’s easier to schedule (usually towards the end of the day). Second, it usually gives me enough time with the candidate so that I end up being pretty confident about how they’ll do both at the job and on the onsite. I haven’t quantified this yet, but anecdotally I have been surprised by onsite interviewer feedback much more rarely when I do this.

Why is this good for the candidate?

It’s one fewer hoop to jump through. Also, whether or not they get along with me as their future manager - both technically and interpersonally - can and should be a pretty strong determinant as to whether they should continue with the process. This gives stronger signal since we are both coding together and talking about work.

When is this a bad idea?

This makes the Hiring Manager a bit of a bottleneck in interviewing; once a company gets to the point where you are interviewing for titles like “Senior Software Engineer, Team TBD” you have to round robin TPS-es to the rest of your Phone Screen Team

Also, as the HM I likely have some unreasonable biases (Golang engineers, I’m looking at you), and making me the bottleneck in interviewing exacerbates those. That said, the HM’s bias is going to be applied sooner or later in the interview process, and my take is that the benefits outlined are worth it.

Tuesday at 4? You sunk my Grooming Session! ↩

A toolset for tackling technical debt

2021-04-01T12:59:39-07:00

Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all.

– Douglas Adams, Dirk Gently’s Holistic Detective Agency

The Situation

“Ugh, the codebase is just such a mess,” my new Tech Lead said. “It’s just cruft on top of cruft, never cleaned up, always ‘after the next release’. No wonder we keep getting bug reports faster than we can fix them.”

Not what you want to hear as the freshly-appointed Engineering Manager on a critical team. Leadership expects the team to deliver on key new features, but also, there better not be any voluntary churn.

I went to talk to the Product Manager. “Tech Debt?” he said, “sure, we can tackle some tech debt - but let’s make sure to get some credibility first by hitting our OKRs. It won’t be easy.”

How did it get this bad?

Cut to three years earlier. I was a new hire on that very team. My onboarding buddy - let’s call him Buddy - and I bumped into a strange corner of the codebase.

“Oh weird,” I said. “Should we fix that?”

“I have a strategy for this that you can use,” Buddy said. “When you run into code that seems off, that feels worth fixing, you write the issue down in a separate text file. Then you go do useful work.”

“Oh, I see. And eventually, you get back to the text file and fix the issues?”

“Nope. But at least you’ve written it down.”

Wikipedia describes learned helplessness as “behavior exhibited by a subject after enduring repeated aversive stimuli beyond their control.” Without support, this is how engineers come to feel about tech debt.

When I came back to this team as a manager, I reached out to Buddy, who had left years ago. “The code is crap at Airbnb too,” he told me when we caught up, “but at least they pay well and I don’t have to work very hard.”

So what did you do?

I joined Airbnb.

That’s not true. We tackled the tech debt. We shipped leadership’s key features, hit our OKRs, and cleaned up some terrible, long-overdue-for-deletion no-good code. Within 3 months, the team’s attitude about technical debt had begun to turn around.

Here’s how.

Tackling Technical Debt In Three Easy Steps

Guaranteed¹.

Step 1. Empower

The biggest reason technical debt exists is because Engineers have internalized that it’s not their job to fix it. Start-up mantras like “focus” and “let small fires burn” have lead to just that - small fires everywhere.

“Get shit done” is a great mantra, but you still have to clean up after yourself.

The fix here is cultural. Make it clear that engineers who identify debt and take time to tackle it are appreciated. Celebrate their work to peers. A friend once created a slack bot that called out any PR that deleted a significant amount of code. Engineers all across the company began striving to get featured.

Now of course, the team does have actual work that needs doing. Empower doesn’t mean “ignore our actual work” - it means, “if you take a Friday to fix something that’s bothering you, I have your back.”

Step 2. Identify

If you’re on a team that hasn’t been rigorous about tackling tech debt, there’s probably lots of it and it’s unclear what could even be done. This is fixable.

Organize a brainstorm with prompts like

What tasks take longer than they should?
What is the most embarrassing part of our code to explain to new hires?
What key pieces of our code have we under-invested in?

This’ll set you up with a solid initial list for your Tech Debt backlog. For more ideas, run your codebase through a tool like CodeClimate to algorithmically point out the rough spots.

The first time we ran a brainstorm like this, everybody agreed that we had a handful of ideas that were so easy and valuable enough that we should do them right away. Like, that day. It felt like a breath of fresh air. Things are fixable.

Encourage folks to add to the Backlog anytime they ran into annoyances and didn’t have time to fix it right there and then. In future team retros or brainstorms, identify any tech debt that comes up and add it onto the backlog.

Step 3. Prioritize

Having a tech debt backlog and ignoring it is worse than none at all.

Time to play Product Manager and use ICE to prioritize your tech debt on effort required to fix, impact that a fix would have on velocity, and confidence that the fix will actually work.

This gives you a list of potential projects. Some will take months; others, hours.

Now they just need to get done. That’ll require buy-in from your Product Manager.

Getting Buy-in

When it’s time to have “the talk” with your PM, I‘ve found “how often should you clean your room” to be useful analogy.

Never cleaning your room is a bad idea and obviously so. Over time it becomes unlivable. This is how our engineers feel. At the same time, if you’re cleaning your room all day every day, that’s not a clean room, that’s excessive and no longer helpful. In moderation, messiness is healthy - it means you’re prioritizing. We don’t need a glistening-clean room, but we do need to do more than nothing. At the end of the day, a clean room is a productive room.

Tackling Small Debt

Come together with your Product Manager and agree to a rate at which small debt projects can get added to the team’s ticket queue. With a spiel like the above, you can hopefully get ~10% of all work done to focus on debt, depending on the maturity of the team and the company.

For ~week-long projects, try to leverage particular times of year like Hack Weeks and pitch high-value projects to engineers looking for a fun project.

Tackling Heavy Debt

This is where good leadership helps. At this particular company, Engineering leadership had rolled out “Quality OKRs”. Every quarter, each team had to sign up for a meaningful “quality” OKR goal.

What is a “quality” goal? This was left up to teams, but the gist of it was, just go fix the most painful thing that isn’t already translated in your business metrics.

During quarterly planning, we whittled the top three “heavy tech debt” projects into proposals, got buy-in from leadership, then brought the ideas back to the group.

Since quality projects had been blessed from top-down and indisputable, the PM had air cover to support the work without pushback.

So what happened?

Was there still tech debt? Yes. Did it continue to accumulate? Of course. But did it feel inexorable? Not anymore.

Not guaranteed. ↩

Technical Interview Superforcasters

2020-12-05T04:24:03-08:00

Originally published as a guest blog post on interviewing.io. Thanks Aline!

“The new VP wants us to double engineering’s headcount in the next six months. If we have a chance in hell to hit the hiring target, you seriously need to reconsider how fussy you’ve become.”

It’s never good to have a recruiter ask engineers to lower their hiring bar, but he had a point. It can take upwards of 100 engineering hours to hire a single candidate, and we had over 50 engineers to hire. Even with the majority of the team chipping in, engineers would often spend multiple hours a week in interviews. Folks began to complain about interview burnout.

Also, fewer people were actually getting offers; the onsite pass rate had fallen by almost a third, from ~40% to under 30%. This meant we needed even more interviews for every hire.

Visnu and I were early engineers bothered most by the state of our hiring process. We dug in. Within a few months, the onsite pass rate went back up, and interviewing burnout receded.

We didn’t lower the hiring bar, though. There was a better way.

Introducing: the Phone Screen Team

We took the company’s best technical interviewers and organized them into a dedicated Phone Screen Team. No longer would engineers be assigned between onsite interviews and preliminary phone screens at recruiting coordinators’ whims. The Phone Screen Team specialized in phone screens; everybody else did onsites.

Why did you think this would be a good idea?

Honestly, all I wanted at the start was to see if I was a higher-signal interviewer than my buddy Joe. So I graphed people’s phone screen pass rate against how those candidates performed in their onsite pass rate.

Joe turned out to be the better interviewer. More importantly, I stumbled into the fact that a number of engineers doing phone screens performed consistently better across the board. They both had more candidates pass their phone screens and then those candidates would get offers at a higher rate.

Sample Data, recreated for Illustrative Purposes.

These numbers were consistent, quarter over quarter. As we compared the top quartile of phone screeners to everybody else, the difference was stark. Each group included a mix of strict and lenient phone screeners; on average, both groups had a phone screen pass rate of 40%.

The similarities ended there: the top quartile’s invitees were twice as likely to get an offer after the onsite (50% vs 25%). These results also were consistent across quarters.

Armed with newfound knowledge of phone screen superforecasters, the obvious move was to have them do all the interviews. In retrospect, it made a ton of sense that some interviewers were “just better” than others.

A quarter after implementing the new process, the “phone screen to onsite” rate stayed constant, but the “onsite pass rate” climbed from ~30% to ~40%, shaving more than 10 hours-per-hire (footnote 2). Opendoor was still running this process when I left several years later.

You should too (footnote 3, footnote 4).

Starting your own Phone Screen Team

1. Identifying Interviewers (footnote 5)

Get your Lever or Greenhouse (or ATS of choice) into an analyzable place somewhere, and then quantify how well interviewers perform. There’s lots of ways to analyze performance; here’s a simple approach which favors folks who generated lots of offers from as few as possible onsites and phone screens.

You can adjust the constants to where zero would match a median interviewer. A score of zero, then, is good.

Your query will look something like this:

Interviewer	Phone Screens	Onsites	Offers	Score
Accurate Alice	20	5	3	(45 - 20 - 20) / 20 = 0.25
Friendly Fred	20	9	4	(60 - 36 - 20) / 20 = 0.2
Strict Sally	20	4	2	(30 - 16 - 20) / 20 = -0.3
Chaotic Chris	20	10	3	(45 - 40 - 20) / 20 = -0.75
No Good Nick	20	12	2	(30 - 48 - 20) / 30 = -1.9

Ideally, hires would also be included in the funnel, since a great phone screen experience would make a candidate more likely to join. I tried including them; unfortunately, the numbers get too small and we start running out of statistical predictive power.

2. Logistics & Scheduling

Phone Screen interviewers no longer do onsite interviews (except as emergency backfills). The questions they ask are now retired from the onsite interview pool to avoid collisions.

Ask the engineers to identify and block off 4 hour-long weekly slots to make available to recruiting (recruiting coordinators will love you). Use a tool like youcanbook.me or calendly to create a unified availability calendar. Aim to have no more than ~2.5 interviews per interviewer per week. To minimize burnout, one thing we tried was to take 2 weeks off interviewing every 6 weeks.

To avoid conflict, ensure that interviewers’ managers are bought in to the time commitment and incorporate their participation during performance reviews.

3. Onboarding Interviewers

When new engineers join the company and start interviewing, they will initially conduct on-site interviews only. If they perform well, consider inviting them into the phone screen team as slots open up. Encourage new members to keep the same question they were already calibrated on, but adapt it to the phone format as needed. In general, it helps to make the question easier and shorter than if you were conducting the interview in person.

When onboarding a new engineer onto the team, have them shadow a current member twice, then be reverse-shadowed by that member twice. Discuss and offer feedback after each shadowing.

4. Continuous Improvement

Interviewing can get repetitive and lonely. Fight this head-on by having recruiting coordinators add a second interviewer (not necessarily from the team) to join 10% or so of interviews and discuss afterwords.

Hold a monthly retrospective with the team and recruiting, with three items on the agenda:

discuss potential process improvements to the interviewing process
review borderline interviews with the group to review together, if your interviewing tool supports recording and playback
have interviewers read through feedback their candidates got from onsite interviewers and look for consistent patterns.

5. Retention

Eventually, interviewers may get burnt out and say things like “I’m interviewing way more people than others on my actual team - why? I could just go do onsite interviews.” This probably means it’s time to rotate them out. Six months feels about right for a typical “phone screen team” tour of duty, to give people a rest. Some folks may not mind and stay on the team for longer.

Buy exclusive swag for team members. Swag are cheap and these people are doing incredibly valuable work. Leaderboards (“Sarah interviewed 10 of the new hires this year”) help raise awareness. Appreciation goes a long way.

Also, people want to be on teams with cool names. Come up with a cooler name than “Phone Screen Team.” My best idea so far is “Ambassadors.”

Conclusion

There’s something very Dunder Mifflin about companies that create Growth Engineering organizations to micro-optimize conversion, only to have those very growth engineers struggle to focus due to interview thrash from an inefficient hiring process. These companies invest millions into hiring, coaching and retaining the very best sales people. Then they leave recruiting - selling the idea of working at the company - in the hands of an engineer that hasn’t gotten a lick of feedback on their interviewing since joining two years ago, with a tight project deadline on the back of her mind.

If you accept the simple truth that not all interviewers are created equal, that the same rigorous quantitative process with which you improve the business should also be used to improve your internal operations, and if you’re trying to hire quickly, you should consider creating a Technical Phone Screen Team.

FAQs, Caveats, and Pre-emptive Defensiveness

Was this statistically significant, or are you conducting pseudoscience? Definitely pseudoscience. Folks in the sample were conducting about 10 interviews a month, ~25 per quarter. Perhaps not yet ready to publish in Nature but meaningful enough to infer from, especially considering the relatively low cost of being wrong.
Why didn’t the on-site pass rate double, as predicted? First, not all of the top folks ended up joining the team. Second, the best performers did well because of a combination of skill (great interviewers, friendly, high signal) and luck (got better candidates). Luck is fleeting, resulting in a regression to the mean.
What size does this start to make sense at? Early on, you should just identify who you believe your best interviewers are and have them (or yourself) do all the phone screens. Then, once you start hiring rapidly enough that you are doing about 5-10 phone screens a week, run the numbers and invite your best 2-3 onsite interviewers to join and create the team.
What did you do for specialized engineering roles? They had their own dedicated processes. Data Science ran a take home, Front-End engineers had their own Phone Screen sub-team, and Data and ML Engineers went through the general full-stack engineer phone screen.
Didn’t shrinking your Phone Screener pool hurt your diversity? In fact, the opposite happened. First, the phone screener pool had a higher percentage of women than the engineering organization at the time; second, a common interviewing anti-pattern is “hazing” - asking difficult questions and then rejecting somebody for “not even remembering about Kahn’s algorithm, lolz.” The best phone screeners don’t haze, bringing a more diverse group onsite.

Lies, Damned Lies, and Front-end Tracking

2020-07-14T12:31:22-07:00

I’m here to warn you about the dangers of front-end user tracking. Not because Google is tracking you, but because it doesn’t track you quite well enough.

What follows is a story in three parts: the front-end tracking trap I fell into, how we dug ourselves out, and how you can go around the trap altogether.

Part 1: A Cautionary Tale

The year was 2019. Opendoor was signing my paychecks.

We were launching our shiny new homepage.

We had spent a month migrating our landing pages from the Rails monolith to a shiny new Next.JS app. The new site was way faster and would therefore convert better, saving us millions of dollars annually in Facebook and Google ad costs.

Being responsible, we ran the roll-out as an A/B test, sending half of the traffic to the old site so we could quantify our impact¹.

The impact we’d made was making things worse. Way worse. The new site got crushed.

What happened?

WTF. Google had told us our new page was way better. The new site even felt snappier.

“Figure it out.” The engineers on revamp paired up with a Data Scientist and went to go figure out what the hell was going on. They started digging into every nook and cranny of the relaunch.

A week went by. Our director peeked in curiously. Murmurs about postponing the big launch started to circle. Weight was gained; hair was lost.

Ultimately, the clue that cracked the case was bounces. Bounces (IE, people leaving right away) were way up on the new site. But it was clear the new site loaded much faster. Bounce rates should have gone down, not up.

How did we measure bounce rates? We dug in.

How bounces work

When the homepage loads, the front-end tracking code records a ‘page view’ event. If the ‘page view’ event was recorded, but then nothing else happens, analytics will consider that user to have “bounced”.

It turned out that the old site was so slow that many folks left before their ‘page view’ ever got recorded. In other words, the old site was dramatically under-reporting bounces.

It was like comparing two diet plans and saying the one where half the subjects quit was better because the survivors tended to lose weight.

Part 2: How we fixed bounces

If the front-end was under-reporting bounces, could we find a way to track a ‘page view’ without relying on the client?

There was. It was on the server - though in our example, we tracked the event in Cloudflare, which we were already using for our A/B test setup.

We started logging a page-about-to-be-viewed event instead of the page view event, which was really page-viewed-long-enough-for-the-tracking-javascript-to-load event. We updated our bounce metrics calculation.

Lo and behold, the new infra was better after all! We had been giving our old page too much credit this entire time, but nobody was incentivized to cry wolf.

Part 3: Front-end tracking done right

Forsake the front-end. Tis a terrible place to track things, for at least three reasons.

1. Performance

The less JavaScript (especially third-party) you have on your landing pages, the better. It’s a better customer experience, and it improves your page’s conversion and quality score.

We calculated that getting rid of Segment and Google Tag Manager on our landing pages would yield about 10-15 points of Google PageSpeed. Google takes PageSpeed into account for Quality Score, which in turn makes your CPMs/CPC cheaper.

2. Fidelity

Somewhere between a half and a quarter of all users have ad-blockers set up. If you’re relying on a pixel event to inform Google / Facebook of conversions, you’re not telling them about everybody. This makes it harder for their machine learning to optimize which customers to send your way. Which means you’re paying more for the same traffic.

3. Powerlessness

You want to believe that you have control of the JavaScript running on your page, but how many browser extensions does the user have? How much has actually loaded? Wait, what version of IE is this person on?

What should i do instead?

Take all your client-side tracking, and move it

to the edge for things like page views (the server is fine, here, though, if you KISS)
to the server for events that have consequences, like button presses.
to publishers for paid traffic conversion, inform Google/Facebook via their server-side APIs when feasible, instead of trying to load a pixel

FAQs & Caveats

Shouldn’t. We used Segment to identify anonymous users; the change was just calling .identify() in Cloudflare (and handling the user cookie there).

I heard server-side conversion tracking for google and facebook doesn’t perform as well.

I’ve heard (and experienced) this as well. We’re entering black magic territory here… try it.

The End.

Want to tell me I’m misinformed / on-point / needed? Hit me up.

We explicitly only changed the infra which served our landing pages, and kept the content - the HTML/CSS/JS - identical. Once the new infra was shown to work, we would begin to experiment with the website itself. ↩

Lessons Learned: Giving Feedback as an Engineering Manager

2020-06-20T07:23:09-07:00

“Alexey, do you feel the points you bring up during our post-mortems are productive?” my tech lead asked at our 1:1.

Well, shit. I had thought so, but apparently not.

Earlier in the year, I became the Engineering Manager on a team responsible for half of the outages at our 2,000 person company. After each incident, the on-call engineer would write-up a doc and schedule a meeting.

“How come this wasn’t caught in unit tests?” I found myself asking, in front of the assembled team. Next post-mortem, same thing. “I get that we didn’t have monitoring for this particular metric, but why not?” Week after week.

The tech lead had asked a great question. Was my approach working?

“I want to set high expectations,” I told him. “It’s not pleasant being critiqued in a group setting, but my hope is that the team internalizes my ‘good post-mortem’ bar.”

The words sounded wrong even as I said them.

“Thanks for the feedback.” I said “Let me think on it.”

Feedback budgets

I thought about it.

There’s a limited budget for criticism one can ingest productively in a single sitting. Managers will try to extend this budget through famed best-practices like the shit-sandwich and the not-really-a-question question. Employees learn these approaches over time and develop an immunity.

This happened here. Once my questioning reached the criticism threshold, I was no longer “improving the post-mortem culture.” I was “building resentment and defensiveness”.

I had run over budget. And yet, there was important feedback to give!

Change the template, change the world

Upon reflection, I ended up updating our post-mortem template. My questions became part of the template that got filled in before meeting.

This way, it was the template pestering the post-mortem author. My role was simply to insist that the template be filled out; an entirely reasonable ask.

Surprisingly enough, this worked; post-mortems became more substantive. The team pared down outage frequency and met OKR goals.

Process linters

One Simple Trick I had stumbled into was that there was a way to get around feedback budgets. Turns out there’s this other, vaster budget to tap into: the budget of process automation. When feedback is automated, it arrives sooner, feels confidential, and lacks judgement. This makes it palatable; this is why the budget is vaster.

The technical analogy here is how we use linters. “Nit: don’t forget to explicitly handle the return value” during code review feels mildly frustrating. Ugh. It’s “just a style thing” and “the code works”. I’ll make the change, but with slight resentment.

Yet, if that same “unhandled return value” nudge arrives in the form of a linter, it’s a different story. I got the feedback before submitting the code for review; no human had to see my minor incompetence.

As a software engineer, Have Good Linters is an obvious, uncontroversial best practice. The revelatory moment for me was that templates for documents were just another kind of linter.

Happy Ending

My insight completely transformed the way Opendoor Engineering thinks about feedback; I crowd-surfed, held aloft by the team’s grateful arms, to receive my due praise as the master of all process improvement.

Just kidding; COVID-19 happened and I switched jobs.

The Appendices Three

I: Process linters seen in the wild

Meetings

Feedback “we have too many meetings”; “what’s the point of this meeting”; “do I need to be here” Linter mandate no-meetings days; mandate agendas; mandate a hard max on attendee count.

Progress Updates

Feedback “Hey, how’s that project going? Haven’t heard from you in a bit” Linter Daily stand-ups (synchronous or in slack/an app); issue trackers (Linear, Asana, Jira, Trello)

Bug Reports

Feedback “Hey, a friend who uses the app said that our unsubscribe page is broken?” Linter Quality pre-deploy test coverage, automated error reporting (Sentry), Alerting on pages or business metrics having anomalous activity patterns (Datadog).

II: You’ve gone too far with this process crap

The process budget is vaster than the feedback budget, but it isn’t unlimited. A mature company is going to have lots of legacy process - process debt, if you will.

Process requires maintenance and pruning, to avoid “we do this because we’ve always done this” type problems. High-process managers are just as likely to generate unhappy employees as high-feedback managers.

III: The post-mortem template changes, if that’s what you’re here for

A. “5 Whys” Prompts

Our original 5 Whys prompt was “Why did this outage occur.” During the post-mortem review, I kept asking questions like “but why didn’t this get caught in regression testing?”

So, after discussion, I added my evergreen questions to the post-mortem template. They are:

Why didn’t the issue get caught by unit tests?
Why didn’t the issue get caught by integration/smoke tests?
Why didn’t the issue get flagged in Code Review?
Why didn’t the issue get caught during manual QA?
If the outage took over an hour to get discovered, why didn’t the monitoring page our on-call?

B. Defining “Root Cause”

“5 Whys” recommends continuing to ask why until you’re about five levels deep. We were often stopping at one or two.

To make stopping less ambiguous, here are a set of “root causes” that I think are close to exhaustive:

trade-off we were aware of this concern but explicitly made the speed-vs-quality trade-off (IE, not adding tests for an experiment). This was tech debt coming back to bite us.
knowledge gap the person doing the work was not aware that this kind of error was even possible (IE, tricky race conditions, worker starvation)
brain fart now that we look at it, we should have caught this earlier. “Just didn’t get enough sleep that night” kind of thing.

If you keep asking “why” but haven’t gotten to an answer that boils down to one of these, keep going deeper (or get a second opinion).

Working Remotely Crossed the Chasm on May 12, 2020

2020-05-12T15:55:46-07:00

2013 Marissa Mayer bans work-from-home at Yahoo
2020 Jack Dorsey permanently institutionalizes work-from-home at Twitter.

Working remotely: not just for COVID-19 anymore.

From academia to the Open Source movement, remote collaboration is not exactly novel. From Github to DuckDuckGo, remote-first successful businesses are no longer rare.

Remote work occupied the cultural relevance of something those whiz kids do, working on a beach in Thailand. Until today.

What has prevented remote work adoption?

Inertia. I have a job and a system that “works” for me. Don’t change what isn’t broken.
Status. I have a “real job” at a “real company.” Working remote is for weirdos and loners.
Productivity. Real decisions happen in elevators on the way to lunch. We know how to be efficient and innovative in-person. How the hell do you build a team remotely?

COVID-19 addressed inertia. Twitter, a Legitimate Tech Company™️, addressed status. Productivity is still pretty hit-or-miss, but it’s early days yet.

Trust me, I’m an expert guinea pig

I came to the Bay Area like a moth to the flame of start-ups after college.

Lacking an H-1B, I left in 2014, and started Hacker Paradise, a boutique travel business catered to remote workers. During that time, I worked remotely as a software engineer for an SF client for over a year.

In 2016, I came back to San Francisco. I did it for the same reason I came in the first place - the quality of the jobs and the community.

I don’t love working remotely. I miss the energy I get from a well-run office environment. COVID-19 has taught me that I’m an extrovert, and shelter-in-place has sucked.

And yet.

Reality is that which, when you stop believing in it, doesn’t go away

- Philip K. Dick.

Implications

1. Remote work is about to do to San Francisco what San Francisco did to the South Bay.

Techies have been leaving San Francisco for cities like Portland, Austin, Denver and Seattle (PADS) for over a decade. We seek a place to settle down and improve cost-to-quality-of-life ratio.

As it becomes easier than ever to keep your job while moving, this trend will pick up. The microkitchens at Twitter are nice, but not “an extra $2k/mo in rent” nice.

As ambitious millennials realize they can optimize for quality of life, expect businesses like Culdesac and Hacker Paradise (see what I did there) to blossom.

San Francisco will neither be abandoned quickly nor completely. It’ll retain a “city emeritus” status, like London, Philadelphia or Palo Alto.

2. We’re going to learn to run remote organizations.

We are, as an industry, pretty clueless at remote company building.

In fairness, we’re not even that good at regular company building. We just figured out 1:1s were a good idea and are still deciding who dotted-lines to whom in the matrix org structure.

You can’t just slap “remote friendly” on your jobs page and decide you’ve done a “heck of a job.”

Should team sizes change? How to you measure and manage morale? What about onboarding and knowledge sharing?

There’s some knowledge to be gleaned from the Basecamp folks; they wrote a book about remote work. That book is the COBOL of remote work; it works, but we can do better.

3. We’re about to enter a renaissance in remote collaboration tooling.

Slack is doing phenomenally well during COVID-19, but it still kind of sucks, right? At least when people emailed you, they didn’t expect a response right away. Etiquette around Slack usage is still pretty immature, am I right @channel?

Also. Software engineers use Github, and it’s a pretty mature way to collaborate on shared work. Every other industry is still sending around Presentation Final Final [2].pdf. Some of my favorite former co-workers are building companies in this space. expect more businesses like Figma and Loom to blossom.

PS. You’re wrong, Alexey. Offices are here to stay.

That’s true. They will.

We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run

- Amara’s Law

The move to remote-as-mainstream-option will take a good decade or two. The inflection point, however, was today, on May 12, 2020.

I for one look forward to kids asking what it was like when I had to leave for work every day.

Confessions of a Deadbeat Open Source Maintainer

2017-05-06T18:06:24-07:00

Create an open source project, they said.

It’ll be great for your resume, they said.

Part 0: Wherein we provide context

The year was 2013, Meteor was the hip new kid on the block and Coffeescript was a reasonable JS dialect choice. We were fresh out of college. Meteor was hosting their first ‘Summer Hackathon’ in San Francisco on 10th and Minna, and we figured this was our shot.

Sequestering ourselves on the second floor of the hackspace, a couple of college friends and I acquired a whiteboard and some markers, and jotted down our big idea list. Not lacking for ambition, the first thing we figured we would fix was server-side rendering. Turned out this seemingly simple task was already on Meteor’s Trello Roadmap, so, what the heck, we figured we’d pitch in.

Speaking with the actual development team a few hours later, we learned that server side was (1) hard and (2) coming soon anyway¹. Fair enough - we’d solve our other painpoint, the lack of a proper admin DSL.

Part 1: introducing Z, the Mongo Admin

Coming from Django land, one of my favorite Framework features had always been being able to describe Admin UIs with a very high level DSL - stuff like

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)
    title = models.CharField(max_length=3)
    birth_date = models.DateField(blank=True, null=True)

leading to auto-generated pages that look like:

Meteor didn’t have an admin DSL² yet. I wanted very much to build one, and a zero-config one (IE, automatically discover your models) at that. I kept suggesting this idea until the others agreed. Leadership.

We cranked out a desired feature-list on a whiteboard. It looked like this.

The List

document view
dealing with arrays
dealing with nested objects
boolean fields
integer fields
editing
auto-discovery & Schema
collection (table) view
home page view
doesn’t look terrible
wrapping the admin into a package.

Then we got started. I hid in a corner and tried to figure out how to get a list of Collections, and the fields in each collection, out of an arbitrary Meteor app. It turned out there was no official way but if I poked under the covers of the undocumented Meteor._RemoteCollectionDriver.mongo.db.collections call.

It turned out you had to ‘warm up’ the _RemoteCollectionDriver (by creating an arbitrary collection) to get the collections loaded. This was the way things worked around Meteor 0.6.

Package loading was the other relatively painful thing - since we couldn’t figure out quite how to get our package loaded last (since we relied on a router and a number of other packages), Yefim solved the problem the pragmatic Hackathon way, and named the package Z-Meteor Admin. This way, unless we relied on a package that decided to start with two Z’s, Meteor would load us last.

Launching with the MVP

Surprisingly, it kind of worked.

We demoed at the Hackathon and even won the ‘Award for Most Technically Impressive’.

Greg and I kept working on the project throughout the summer and fall of 2013. We cleaned it up and released 1.0 in December 2013, after gaining over 200 stars on Github.

For our 1.0 release, I demoed a slightly-less-hacky-and-now-renamed Houston Admin at Meteor Devshop 10:

Here’s the blog post I wrote to celebrate the event.

Part 2: A primer on gas tank emptying

Between the 1.0 in December 2013 and roughly summer 2014, our enthusiasm for working on the project waned. There were many reasons, but here are some:

1. We had shit to do.

Greg finished school and was working for Gumroad, not in Meteor. I was doing consulting/startup prototyping work, also mostly not in Meteor. Yefim & Ceasar made the wise decision of not doing much contributing work past the initial release.

2. We were no longer scratching our own itch.

Originally, Yefim and I used Houston for the Intern Dinners we were running that summer. It was pretty helpful, and if we needed more UI stuff, we’d just add it. That was summer 2013.

Even though many of the feature requests we were getting were quite sensible (and we implemented a bunch of them), we really weren’t scratching our own itch after summer 2013.

3. ‘How do I even’-esque Github Issues

Actually, having gone through some of the ~270 Github Issues on the project, I’m surprised by how good many of them were and how attentive and friendly we were about them. Still, there were a few bad apples, like css not rendering, how to upload files and Cannot login on Heroku app that either failed to provide enough context and/or were coming from folks who were not otherwise yet competent Meteor (or even JS) developers.

4. Meteor doesn’t support Mounting & hacky CSS.

Meteor bundles all CSS & Javascript together when it compiles. This is not the ideal behavior for UI libraries, since if the parent app has some logic that say, for example $('.save').disable() and later the user goes to Houston, all of a sudden all of our ‘save’ buttons are disabled and its unclear why. Likewise, any global CSS rules the parent app chooses to use, like (say) making table columns 200 pixels high, will also make our table columns 200 pixels high. Greg did some crazy things to avoid the namespace collissions.

Django solves this problem through URL namespaces, allowing the ‘admin’ to behave largely like its own app. Express.js allows for ‘mounting’ of multiple sub-apps on certain directory paths - in either case, no shared CSS/JS is bundled for these cases, avoiding collissions like the above.

Meteor did not support Mounting out of the box. I bugged the devs about it at a later Devshop, and got an off-hand note that this was not a priority for now. Later on we tried to add Mounting to Meteor and/or host the Admin as a separate app that shared only the database with the parent app, but by then lacked the enthusiasm to bring the projects to completion.

5. Testing is tough!

Reactive apps with not a ton of business logic are tough to test! Perhaps we simply lacked the experience here, but when Greg and I tried to add proper integration tests to the app, we spent tens of hours being our heads against the wall, time that would have been better spent actually fixing bugs.

6. Router Wars

When we created Houston in summer 2013, there was a router that I believe was just called Router. Later, Iron-Router becames the default router (perhaps this was a rename?) - and even later, Flow-Router became the preferred router. Here’s a post on the state of routing as of Summer 2015.

The point was, you couldn’t really use both routers and so we would need lots of clever work to see if we could support both paths. We discussed this in a Github Issue and I wrote up a prototype but ultimately just didn’t have enough time/energy to ship a supports-both solution.

7. When Undocumented Internal Dependencies Change

Remember that _RemoteCollectionDriver hack? In most every release (0.7, 0.8) my ‘whatever, go ask mongo what collections there are’ hack kept breaking and I had to re-implement a new hack based on whichever refactor the Meteor Development Group implemented internally.

Not particularly taxing, but just a drain.

8. We never stepped back and thought about architecture.

Things were in slighly better shape than they were back during the hackathon, but there was never a “how should this package be properly architected” conversation. As a result, in later months as I tried to go back and implement changes, it was never clear to me what was where or why, or what edge cases I would need to consider and support. This made “weekend-a-month” type support less useful over time as I knew the codebase less and less well.

Part 3: Where we go to Costa Rica and try to turn things around

Costa Rica: the plan

Around Summer 2014, a year after we started, things were going kind of slumpey. As an effort to regroup, I invited Greg to Costa Rica where I was staying for a few months:

The plan was basically to unbreak the critical stuff and make a plan for what we wanted to do next, and maybe also play some soccer on the beach.

Costa Rica: what actually happened

I got bogged down on a consulting project that was a bit behind schedule as Greg visited. So we got maybe 1-2 days of work done, which instead of dealing with any of the issues on my part was shipping a new feature I decided I wanted, called Custom Actions, which were kind of cool but not at all the problem.

We still played some soccer, though. Greg was way better at soccer than the rest of us.

Get other maintainers, they said

We had two pretty helpful maintainers turn up: First, Roger decided to redesign our UI from basic boostrap to the line-green version you see today. Second, sometime around late 2014, this Swiss dude named Matteo showed up and fixed a bunch of things. That was awesome, and we talked to him on Skype and gave him write access as somebody had suggested for growing your maintainers.

Later, in 2015, my friend Sam came in and added some proper tests, but development had largely ceased by then.

Still, for whatever reason, nobody stuck around and answered issues, etc, for the long term, so it was still up to us.

Part 4: Decline and Fall of the Houston Admin

Meteor 1.0 is released!

Coinciding with Greg’s visit, Meteor finally released 1.0 in October 2014. Perhaps we’ll no longer have to adjust the incompatible hacks we use to figure out which collections are to be added and we can focus on the good stuff!

Blaze vs React

If only. A year later, the big question up in the air becomes whether to use Meteor’s original Blaze templating or switch to a react-based front-end. React is great and all, but we for one are not up for yet anothe rewrite of this thing we haven’t really gotten to use for our own stuff in like, two years.

1.3

To add insult to injury, The Meteor Development Group ignores the principles of Semantic Versioning to release 1.3 in April 2016 with Breaking Changes - and our package is broken yet again. Maybe.

Part 5, an Epilogue

Perhaps the most poignant symptom of the sort of stagnancy that the project fell into is that I had an idea to write this blog-post in early 2015, and it took two years to even get the post-mortem for this project done.

I think Greg may have fixed the 1.3 issue, but the last change I can see in the codebase is in March 2016 and frankly I just don’t care anymore. On the bright side, it looks like there’s a half-decent competitor that people who want an admin can use³. Also, the Meteor Development Group looks like it’s less interested in Meteor and focusing on GraphQL tools these days, so maybe nobody needs this. On the bright side, 880 stars on Github, so that’s cool!

What have we learned?

Open-source maintenance is hard, especially if your only remaining motivation is altruism. Richard Schneeman gave a great talk about Saving Sprockets last year which nailed it.
Perhaps we should have quit while we were ahead and put an “not actively maintained, looking for maintainers” on the README back in 2014. That would have been a bit more responsible.
On the bright side, building a key piece of infrastructure for a hip new development framework turned out to be a great way to get a lot of users for your open source project.

…one more thing

I leave you with the contributions over time graph, which tells the whole story, but with graphics.

Thank you

To Greg, the prospect of collaborating with whom kept me in the project as long as it did.
The Yefim, Ceasar, Matteo, Roger, Sam and other contributors!
The the Meteor Development Group folks for their contributions to realtime web development, whose ideas will live on independent of Meteor’s future, and also for the free snacks and t-shirts and the Pebbles we won at that hackathon back at 2013.

as far as I know, Meteor still doesn’t have proper Server-Side rendering. Arunoda wrote a community library in 2015, but given the Blaze/React split, I’m uncertain how much of this has come to pass. ↩
Ironically, the closest thing to an Meteor Admin at the time was Genghis, a standalone one-page PHP-based Mongo editor by Justin Hileman, whose younger brother I had somehow hired the year prior. Silicon Valley is a small place. ↩
though it too looks like it has not been updated in 10 months :-/. ↩

Test Driven Interviewing

2017-05-06T11:31:37-07:00

For most¹ engineering tasks, I prefer to avoid TDD, or Test Driven Development.

Yet when I job-hunt, I use TDD religiously². It has been tremendously helpful.

Hmpf. Why?

Most interview challenges actually come in two parts.

Can you take a broadly-worded problem and nail it down into something unambiguous?
Can you implement a challenging but unambiguous spec in the allotted time?

TDD forces you into the ideal mindset for nailing down (1) problem definitions. There’s no better way to properly grok a problem than to have to think through all the fun ways an implementation could be slightly off.

The implementation itself (2) also gets easier since you no longer have to assume that your code “probably” works, or fiddle with a REPL each time you’re ready to check.

So how do I do it?

As soon as you hear the problem, resist the urge to rush straight to the solution.

Instead, force yourself to fully think through the test cases for an arbitrary implementation. Make it a dialog - “what if the same element is in the array multiple times?” Get the interviewer engaged. Show you care.

By the time you’ve written good tests and the interviewer agrees, you’re all set. Even though you tried not to, you probably already have a decent solution in mind. Your tests will let you know you’re done. They’ll also give you the comfort that your subsequent clean up / refactoring doesn’t inadvertantly break your implemenation.

Yeah, but I can always just write tests later.

When I conduct interviews, I keep running into candidates clever enough to power through engineering challenges on raw talent³. The candidate implements an optimal solution within fifteen minutes. Then it’s time for tests and she just cannot think of cases beyond the common path, which makes her look like a cowboy.

I blame the curse of knowledge - once you’ve solved the problem, it’s harder to think about what wrong turns you could have taken. It all feels trivial.

Seriously though, are you going to make me import a testing framework? Like, Mocha or Cucumber? Ugh.

¯\_(ツ)_/¯, I just use asserts and print statements. If I’m feeling fancy, I’ll create an array of test case scenarios and run them like

test_cases = [
  [[2, 2], 4],
  [[1, 2, 3, 4], 10],
  [[], 0],
  [[-3, 2], 1],
  [[100, 2], 102],
  [["banana"], None]
]

for test_case in test_cases:
  args, expected_answer = test_case
  answer = quantum_addition(args)

  print("called add({}) and got {}, expected {}"
    .format(args, answer, expected_answer))

  if answer != expected_answer:
    print("UH OH!")

  # (or you could just do: assert answer == expected_answer)

If you insist on being fancy, you can do that thing where you ask your interviewer if they’d like you to use a proper testing framework first, and of course they don’t, but now it looks like you could and you’re just doing them a favor by using asserts, cause you’re like, super assertive.

Ok so now what?

Well obviously you should come work at Opendoor with me! We have the good coconut water and don’t run out of it until like noon, 12:30 on good days. Plus, there’s a decent chance you’ll run into me on your phone screen and we can have that awkward interaction of trying to figure out why my name sounds familiar.

Thanks to Vaibhav, Joe, Nick, Gayle, Tess, Charlie, Kevin, Zain, and Yahel for giving feedback on earlier drafts that I incorporated.

Don’t get me wrong, TDD has its uses, but we often mistake what Kent Beck meant by ‘unit’. Testing ‘just right’ is hard. ↩
To be clear, TDD won’t help you with interview where you don’t actually code (IE, whiteboard interviews) You’ll still have to start by asking questions, though. ↩
I used to have that problem earlier in my career. I’ve addressed it, largely by becoming dumber. ↩

Two Steps Forward, Two Steps Back: 2016 in review

2017-01-03T10:31:37-08:00

2015 and 2016 could not have been more different.

2015 was mostly spent living out of a carry-on bag, traveling from Estonia and Berlin to Tokyo and Taipei helping run trips for, and building, Hacker Paradise.

It was great. Wanderlust: satisfied.

2016 found me receiving an H1-B visa, moving back to the Bay Area, and obtaining honest-to-goodness employment. Different.

Here’s how becoming sedentary and employed has turned out so far, relative to expectations.

The Good

Basically, stability.

Engaged

My partner Mari¹ and I are (at long last) engaged! After 5 years of being together, we’re back to living together and have a place in Bernal Heights that feels like our own. We’re so domestic we even got an L-shaped couch and the kind of mattress they advertise on podcasts.

There’s something very warm and comforting in having a good sense of who you are going to spend the rest of your life with. Mari has been an anchor, making the disruption in other parts of my life that much more manageable.

Friendship & Community

It’s also been rewarding to be able to engage and re-engage in meaningful friendships. One of the toughest parts of traveling full-time turned out to be meeting new people every month (great people, mind you) and forging friendships with them. At some point, the task became exhausting. I yearned for the comfort of spending time with the sort of friend that already knew my jokes were overly-complicated and terrible and would laugh anyway, if only on the inside.

I’m still not 100% back to feeling integrated or satisfied with the depth of my relationships back in San Francisco, but compared to full-time travel, the improvement has been remarkable and the last few months of 2016 felt much better than the months prior.

J.O.B.

I joined Opendoor in September. Part of the motivation of being an employee was to have co-workers I would learn from & enjoy working with. This came true. Another part, which I was more surprised to learn, was that “Growth Engineering” - a term I would have thought ridiculous back in college, and as a sell-out-sort-of-a-thing-to-do, is actually quite engaging and satisfying. It feels like I’m doing behavioral economics research again, but with higher stakes. I’m very grateful to Remi Gabillet, for first identifying this role for me.

Opendoor has easily met expectations in terms of the company’s growth, the quality of my coworkers, my faith in the executive team, and my ability to have an impact as an individual contributor joining a 150+ person company.

The Bad

There’s no better crutch for procrastination than employment.

Balance

A problem that I’ve seen a fair bit with engineers and especially founders in tech is this mission-at-all-costs mentality. Like political operatives on a critical campaign or soldiers in the middle of a war, it’s easy to say “this thing I’m part of is more important. I can postpone [personal thing that I should get done] for now, because if we win we can always deal with it later.”

And then the mission comes to an end and we’re stuck figuring out that we’ve got to find a way to do our own laundry and maybe go to the gym more often and our last annual check-up was in the last decade. Maybe you deal with it, but often you start hoping and searching for another mission to come along because it’s easier and you don’t have to do boring, mundane things like take care of yourself.

One of the reasons for deciding to get a job rather than starting another company was that I could use the superior work-life balance to get the rest of my shit in order, and avoid getting caught in the mission-at-all-costs mentality.

That hasn’t really happened.

It did, a little bit, at Sprig. But at Opendoor, working harder and staying longer has been too gratifying, too tempting to be easily avoided, and I found myself slowly falling back into using mission-at-all-costs excuses².

Consequences

As a result, I’ve definitely gained some weight (something that did not happen while traveling and eating at restaurants full-time for a year and a half). I’ve ignored a doctor’s note to start watching my cholesterol. I missed a dentist appointment. I bike to work but have failed to follow a regular gym schedule.

I also have yet to deal with setting up some nuances relating to my Health Savings Account. I have an accident claim from a rental car that got broken into that has been pending since September.

I planned to set concrete mental health goals around building resilience and good habits, and meet with a therapist regularly³. Still TBD.

Instead, I’ve reverted to occasionally staying up way later than I should and then being less productive at work the next day - essentially a high-school version of myself but with more severe impact to my productivity, given I’m not sixteen anymore.

My lifestyle has me eating less healthily and drinking more than when I was traveling, on “vacation”.

I find myself easily falling into many of the typical privileged-engineer-at-a-legit-startup-in-the-bay-area traps. It’s funny but also a little disappointing, since I was well aware of (and caution others) against this kind of self-neglect. I’d rather be making new mistakes.

All in all

Some good, some bad. As far as new year’s resolutions go, I’m going to need to make sure to be hitting the original goals I had in mind when I moved back to San Francisco.

2017 Goals

Sleep Maintain a healthy sleep schedule (7+ hours of sleep and in bed by 1AM, 95% of the days of the year).

Exercise Do something (bouldering, gym, or other form of exerfise) 3+ days a week, 95% of weeks except vacation. Reach and maintain target weight of around 10 pounds less than Jan 1st, 2016.

Mental Health Build mental resilience (either follow a book or hire a therapist by Jan 30; create a growth plan; follow said plan).

Physical Health

Schedule & attend follow-up physical by Jan 30; follow recommendations.
Schedule & attend dentist appointment by Feb 30.

Writing (AKA, other interests)

Publish a 500+ word piece once a month, including receiving quality feedback from friends.

Fingers crossed.

I have to say I’m pretty stoked to stop explaining why I use “partner” and just saying “fiancee”. ↩
More caveats: Opendoor is a great place to work and if I haven’t tried convincing you to join yet, ping me. ↩
I assume that by 2017 this is not a controversial position. To be explicit: I’m not in any particular trouble, other than the sort of typical garden-variety depression and anxiety you’ll often see in ambitious over-achievers. You don’t wait until you’re overweight to start exercising; you shouldn’t wait to be struggling emotionally to work with a professional to build resilience and maintain mental health. ↩

Dependonate: Donate to your dependencies

2016-03-10T12:51:31-08:00

Giving back to open source projects you benefit from is one of those obviously-good-in-theory-confusing-in-practice ideas, like eating healthy or being carbon-neutral.

Many services - flattr, bountysource and gratify, among others, offer widgets that developers can put on their projects to encourage subscription donations. None has been a breakout success.

There needs to be a fast and straightforward tool to empower an engineering manager to say “sure, let’s do it.”

Dependonate

Here’s how it would work.

Dependency File

Most projects I work on these days have a file with a list of package dependencies - Gemfile for ruby, requirements.txt for python, package.json for node, and plenty more.

List of Dependencies

Piggybacking on package managers files, Dependonate would take a project’s dependency file and generate a list of direct and indirect projects. Each of those projects can then be parsed to see whether their Readme file includes links to any of the popular donate options (flattr, bountysource, gratify, paypal, etc).

Actionable Next Steps

Finally, Dependonate would open up the various URLs that would make donating as registering and entering your credit card on the services above, the lists of desired projects to contribute to having been auto-filled.

Dependonate would also generate a pretty report for the company to put up on their website as proponents of Open Source, somewhere near the engineering hiring page.

Hit me up if you build something like this, or if your company would be up for donating through it.

Flystein saved me over 1000 dollars on flight costs and all they got was this blog post

2015-10-05T13:53:30-07:00

I found myself planning a series of flights for Hacker Paradise, flying from Tel Aviv –> New York –> San Francisco –> Tokyo –> Tel Aviv with a few days of flexibility for when to take each flight. I spent about half an hour on Skyscanner and Google Flights, and couldn’t find flights for less than about $3,000. Which is a lot. At roughly the same time, Vlad from Flystein reached out and offered to help Hacker Paradise participants book flights. So I tried the service out.</strong></p>

What’s Flystein?

Glad you asked. Flystein, it turns out, is what a value travel agent looks like in the “digital age”. Instead of making money by taking a percentage of your booking fare from airlines, Flystein helps you find the cheapest possible fare online that meets your needs and then charges a flat fee for doing so. You then book the flights yourselves, via links & booking instructions Flystein provides.

Taking money for providing value. Who knew.

How did it go?

I gave Flystein my itinerary and neurotic set of flight cost preferences.

A day later, they came back with flights totalling $1934. A ~$1,150 difference between a “reasonably competent” online flight shopper like me and a bona fide flight expert.

How did things get so much cheaper?

Throwaway Ticketing. My Tel Aviv to New York flight includes a roundtrip flight back to Copenhagen in February. I’m probably not going to take it, but who knows. Also, who cares – it was $200 or so cheaper than the equivalent one-way flight. I would have never known to check.

Hidden City Ticketing. My San Francisco to Tokyo flight included a day-long layover in Tokyo and then continued on to Hong Kong. I, however, never made it on the connecting flight. One day, Hong Kong, one day.

The Economist has a good write-up of the hows and whys and economics of flight hacks. The point is, you can save a considerable amount of money on flights if you know what to look for and are willing to dedicate the time required. Or you can use Flystein.

How was booking?

Mostly fine. One of my flight legs was expired by the time I looked (you have to book quickly) and I ended up calling British Airways, only to be told that I needed to pay thousands of dollars more.

So I let Flystein know. After cursing about British Airways for a bit, Vlad found a flight that worked perfectly only a few minutes later. The new flight cost a whole $20 more.

The whole booking episode could have been avoided if I had the ability to go full “travel agent” and just given Flystein permission to book on my behalf. It turns out there are legal reasons why doing so is not trivial, but they’re on it.

Was it worth it?

Flystein saved me over $1,000. Research fees for a trip like mine cost <$100 (a simpler flight starts at $49). So, yes. 90%+ of the savings for near 0% of the frustration in finding & booking flights. Value….but what if they don’t find anything? Fair question.

It’s possible you’ve already found the cheapest rate you’re going to get. Flystein has a beat-my-price option where you only get charged if Flystein actually saves you more than their fees.

Flystein. Use it when booking flights of non-trivial complexity (international flights over $500). It’s a thing.

Hackathon - A retrospective - a talk

2015-06-22T12:53:52-07:00

Nick Meyer and I gave a talk at HackCon II in February about a hackathon we ostensibly threw.

Hackcon III is at Github HQ in SF this summer.

Did I say Estonia? I meant Costa Rica

2014-08-01T04:27:40-07:00

I’m putting Estonia on hold - still excited to go there, and hoping to do so in April or May, once it warms up again.

In the meanwhile, I’m heading to Costa Rica to help facilitate Hacker Paradise a 12-week digital retreat. The location has all the benefits of nomadism (cheap, beautiful location with delicious food and friendly people) while bringing together a small community of hackers working on individual learning, contracting or their own companies.

Here’s how it happened: Casey Rosengren, a Penn classmate and fellow Penn Hackathon organizer, was doing the whole travel-and-freelance thing and did some work for a boutique hotel that was down to give Casey the entire place for a couple of months, leading to the creation of Hacker Paradise. I saw one of Casey’s posts about the place, and offered to come help.

In short: I’ll be hacking by the pool in Costa Rica until November if you need me.

</img>

PS. Care to join, either for the whole 12 weeks or for a shorter trip? We’re keeping a couple of spots open.

When visas turn into pumpkins

2014-07-03T18:06:24-07:00

TL;DR: My US work visa runs out in a month, so I’m leaving for about a year to go travel. I start on August 2014.

…actually, that’s it.

FAQ

Wait, you’re not American? I’m an Israeli citizen born in Ukraine. I came to the US for my undergraduate degree. I kind of sound American because I went to the American International School for elementary through high school in Israel.
So what’s the story with the visas? I was able to stay in the US on my F-1 (student) visa for two a half years after graduation through OPT and STEM. This year, I applied for an H1-B visa with a sponsor - there were 172k people for 85k slots. There was a lottery, and I didn’t make it. Could have been worse.
Well, that sucks. Anything I can do to help? It’s fine, really. Thanks for your concern! I’ve been meaning to travel for a while, so the timing works out. If you’d like to help,
- Recommend particular cities that you think would be great places to live for 2 months
- If you know any good companies that do remote work, I might be interested
- …actually, if you have the space and aren’t planning to move for a year, I wouldn’t mind storing a bit of stuff in your basement
What’s the plan? Largely TBD, but the tentative plan is to live in six different locations for about two months each.

The first stop is Tallinn, the capital of Estonia. Why? Wired swears by it, and my further research confirms Tallinn should be an interesting place. I don’t know if I want to work on my own ideas or contract remotely yet - time will tell. Plans are still up in the air for the next destination, but I am hoping to get a couple of months of skiing in over January & February.

That sounds fun! Can I come visit? Absolutely. My plan is, rent prices permitting, to have a guest bedroom in every place I’ll be living in.
…so, are you coming back? I certainly plan to. I love it here.
Our immigration policies are ridiculous! That’s not a question. Also, politics is hard! If you want to help, consider supporting fwd.us or one of many other immigration reform groups.
Let’s hang out before you leave! Totes. Email me and let’s try to find a time and a place.

Hackonomics 101

2014-02-04T16:12:16-08:00

I helped organize HackCon, a conference for student hackathon organizers, this past weekend in NY.

I gave a talk about Hackonomics, trying to quantify the financial benefit for hackathon sponsors and figuring out what the future looks like. I then annotated the slides - on Medium, for a change.

The writing style here is a lot more like the talk I gave - more stream-of-consciosness than well-organized. Different, but not necessarily worse. Hopefully.

Houston Admin Talk at Meteor Devshop 10

2013-12-19T11:15:34-08:00

I gave a talk at the latest Meteor Devshop a couple of weeks ago about Houston, the Django-Admin like tool that Greg, Geoff and I are working on for Meteor.

With over 200 stars on Github, I think we might almost be real Open Source Contributors now. It’s fun!

If you’re into web development and Javascript and real-timey things, check out Meteor.

If you already know about Meteor, you should try Houston.

If you already use Houston (whoa, thanks!) check out the feature wishlist and send us some pull requests!

PS. I thoroughly enjoyed TA-ing in college and I miss it, so public speaking on technical subjects is a ton of fun (though nerve-wrecking) for me. If you’ve got tips for things I should work on after seeing the talk, please email me!

The last 10 months

2013-10-20T09:25:18-07:00

2013 hasn’t been a great year for new content on this blog. Let me try to change that.

###First, what’ve I been up to since January?

I did some engineering consulting work, with the bulk of the time spent working for Baydin, Tencent and Dropbox.
Started The InternProject, a “let’s make sure interns in the bay area have a great time” non-profit with Alex, with major help from Tess, Geoff, James and countless others.
Became a real open-source contributor via ZMA, a CRUD Admin tool for Meteor, with Geoff and Greg. Greg’s been keeping the project updated. I need to contribute more.
Worked with Amy to start the Campus Data Summit, creating the Campus Data Guidebook for students starting PennAppsLabs-like organizations at their schools.
Generally speaking, figured out what I enjoy and what I don’t enjoy, and what I want to do next.

=========

Contracting

It took a while to get my first gig - the first 7 or 8 companies I spoke with all ended up passing, for various reasons, which put a fair bit of dent in my plans. I came up with lots of ways to get more inbound flow, but didn’t have the energy to execute any of it because I was so tired of rejection. Basically, if you’re burnt out and trying to recover, putting yourself in a position to get rejected a lot is not a great idea.

Eventually, I refined and simplified my pitch, going from “co-founder for rent”/”on-demand hiring manager” to a much simpler one - “I can code, and I don’t need to be micro-managed on product.” That worked.

I spent the first ~10 weeks at Baydin, the makers of Boomerang for Gmail, pitching and then adding a feature to Boomerang Calendar. I’ve been fascinated by scheduling tools ever since I saw Tungle.me, so it was tremendously rewarding to work on this problem, and the Boomerang team both provided awesome leverage and feedback, as well as giving me a lot more autonomy than should be reasonable. An awesome and very small (<10) person team in Mountain View - a fantastic place to work. My updates to Boomerang Calendar deserve their own blog post. Hopefully.

Next, I worked at Tencent, a giant Chinese tech company (think AOL or IAC, but more successful) with an office in a church in Palo Alto. The people were great and I appreciated the opportunity to work with them, but the biggest thing I learned was that larger, more traditional companies are not places I thrive.

Finally, I spent two and a half months at Dropbox, working on Dropbox for Business. From Soleio to Guido to Aditya and Ruchi, to (more anecdotally) a few friends I have a ton of respect for, Dropbox has been making some killer hires over the past year and I couldn’t help but want to see why. Now I know (hint: it’s the cafeteria). Dropbox is an absolutely fantastic company with a rather talented group of people, and (I imagine) a lot like what Facebook felt like in 2008 or 2009. Drew is a fantastic public speaker and generally an affable guy.

Each of the three gigs above was a 4-day-a-week kind of job, and I learned a lot from each. The thing that most stuck with me - and I was a little surprised by this - was how much fun I had working on Boomerang Calendar. I worked in a mostly-solo capacity, but with design and library engineering support when needed and great product people to brainstorm and prioritize with. I want to do more of that.

###The InternProject I’ve written a whole bunch about recruiting and internships in the Bay before, and started the 2012 Bay Area interns Facebook group. Still, the problem of “how do you make sure people doing internships in the Bay Area get the value out of it that they can” - admittedly a first-world problem, but my first-world problem, didn’t feel completely-solved.

I had met Alex Poon the prior year, when he organized a number of intern dinners. We brainstormed about what the ideal solution would look like - a single website with everything you need to know, a big kick-off event for interns from small companies to meet others to hang out with during the summer, and a way to generally keep in the loop on what the good events were. Out of this came the InternProject, which (it seems, so far) met our goals for the summer and then exceeded them.

We’re still figuring out how to transition the project to being student run - Alex and Tess dropped out of school and I graduated. We’ll see. The important thing is that the ~2,500 students on our list-serv found it to be valuable, according to click and open rates.

What’s next

I’ve begun to consider folks like Marco Arment and Loren Bricter as role models rather than just fascinating people. In the long run, I’d love to get into a place where I can make apps that I consider interesting, ideally focused on productivity or developer tools, and have the occassional engineering/design/product support necessary to keep me focused, all the while avoiding management as much as possible. Baydin was a ton of fun. I’d love to replicate that experience, if I can.

In the meanwhile, I’m playing with an entirely different idea that probably deserves its own blog post.

I want to explore whether the reasons that recruiters have a poor reputation in the industry (spam, sketchiness, competence) are an unavoidable side-effect of the industry model.

To do that, I’m spending the next few months figuring what its like to be a full-time technical recruiter, but eliminating all the parts I don’t like.

We’re focusing on seeing if we can be Talent Advocates, helping rising seniors in CS figure out what to do with their lives and monetizing by putting students in touch with companies that help them get there. I want to know if (1) there’s a business here, (2) if I can add enough value to have a clean conscience, and (3) if I can do the work. Follow along at threesat.com.

Migrating Divvy configurations between computers

2013-06-18T20:27:28-07:00

August 2016 Update: Divvy now has a native guide for migrations. Use that instead.

If you’re having trouble importing, it might be because the URL Divvy gives you is too long. I solved this (on a Mac) by, rather than pasting the URL into the browser, opening a terminal window and typing.

open ‘Divvy Backup URL’

instead. (Where the ‘Divvy Backup URL’ is the one you got when exporting

I’ve been using Divvy the tiling tool for OSX (and windows) ever since I switched to using Macs full-time in 2010. It’s great.</p>

I’ve been using Divvy the tiling tool for OSX (and windows) ever since I switched to using Macs full-time in 2010. It’s great.

Migrating it between installs isn’t so great, and unfortunately googling “migrate divvy preferences” doesn’t help. So, while moving to yet another Mac, I emailed support@mizage and asked what to do.

Here (with their permission) is how to migrate your divvy settings / preferences / configurations / setup / whatever to a new computer:

If you’re on Windows:

0) Quit Divvy on both PCs.

1) Click Start > Run, and paste in this command:

%USERPROFILE%\Local Settings\Application Data\Mizage LLC\Divvy

2) This should open a new Explorer window.

3) Locate the file shortcuts.db

4) Copy that file to the same location on your second computer.

If you’re on Mac:

0) Quit Divvy on both Macs.

1a) If you’re on Snow Leopard, go into your User’s Library folder in Finder.

1b) If you’re on Lion or later, open a Finder window, now hold the Option (alt) key and choose the “Go > Library” menu item.

(AMK Note: this is at ~/Library/Preferences)

2) Go into the Preferences folder.

3) Locate the file com.mizage.Divvy.plist

4) Copy that file to the same location on your second Mac.

Regards, Steve

Thanks Steve!

The Art of Rejection

2013-04-07T16:11:47-07:00

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.

Start-ups are hard: Lessons learned in 2012

2013-02-24T09:45:51-08:00

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.

Hackathon Hacks for Organizers

2012-10-12T12:48:10-07:00

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

</img>

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

</img>

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: </img>

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.

</img>

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

</img>

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.

</img>

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

</img>

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.

How PennApps Labs Came to Be

2012-08-26T14:38:18-07:00

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.

FundersClub: getting Crowdfunding right

2012-08-12T14:26:23-07:00

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.

</img>

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.

</img> </img>

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.

Being safe with mongodb

2012-08-05T16:45:08-07:00

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!

Sidecar and Digital Reputation Systems

2012-07-29T16:23:57-07:00

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.

</img>

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.

My $370 Adjustable Sit-Stand Desk Setup

2012-07-22T14:54:14-07:00

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.

</img>

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.

</img>

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.

Weekend Hack: A Markov Baby Name Generator

2012-07-15T11:00:11-07:00

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.

</img>

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.

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.

Non-Technical Hiring, Lessons Learned

2012-07-07T19:34:00-07:00

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.

Migrating from Posterous to Jekyll on GitHub Pages

2012-07-01T16:30:00-07:00

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.

My first time with an Exec

2012-06-18T19:34:00-07:00

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.

Cost: $75 ($25/hour)

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.

Takeaways for next time:

Do it yourself first. I saw the opportunity and got excited about using Exec. The right thing would have been to go through 2 or 3 people myself first, understand my workflow, verify whether it was outsourceable, and only then document it and pass it on. If I were doing this again, I would probably read the comments myself and only ask to get the executive summary of a commenter be done for me externally. This would have probably only taken about 1 hour of exec-time.
Give feedback early. I should have asked Sarah to check in after she finished each of the first few people so that I could give feedback and refine the task. In a couple of the cases, she added information that wasn't useful that I could have blocked earlier on.
The Exec is not your clone. I expected too much tech-related domain knowledge out of my Exec. My description was wishy-washy and hoped for the best. Part of this, I'm sure, will come with expertise, but from now on I will try to describe too much rather than too little if I'm working with somebody new.

Verdict: I'll be back on Exec, less naive and frivolous about asking for tasks before I understand what I really want. Here's $5 off if you'd care to try it out.

A blog post a week, or the beer's on you: Iron Blogger SF

2012-06-10T13:02:00-07:00

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.

Don't take your highest-paying internship offer

2012-05-19T03:37:00-07:00

"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]

So those co-founder slides turned into a TechCrunch article

2012-04-15T07:46:00-07:00

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.

A brief guide to tech internships

2012-01-30T00:12:00-08:00

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?

(via Dave Miller)

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.

Don't make me wait for bags at the airport, just deliver them.

2012-01-17T01:17:00-08:00

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?

Cool Story, Bro: Stephan from Kembrel

2011-12-22T07:07:14-08:00

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?

Stephan is originally from Germany, where he served as a Special Forces Sniper for the German military. He's also a former Computer Science undergrad, having taken time off to work as a developer in NY, and a former consultant, and a recent Wharton MBA grad (which was how we sort-of-but-not-quite knew each other). In short: Stephan is this guy.

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.

"The numbers for physical stores are really, really interesting," explained Stephan. "If we get somebody to walk inside, the odds of them buying something are absurdly high." The odds of them signing up online are significant as well. Online-to-offline and back to online commerce is a fun and nascent market, and Kembrel's current positioning and tech-savviness puts them in a place to be amongst the first to figure out how all this "get people online to come to your store, get people in your store to visit you online" stuff works.

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)

Post-Finals Doughnuts and Hot Cocoa: This is obvious, but...

2011-12-19T06:09:00-08:00

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

Finding a Technical Cofounder: Slides from talk

2011-11-14T11:45:00-08:00

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

The Mentorship Checklist: 9 questions for your potential employer

2011-11-01T06:00:00-07:00

You: a CS student looking for your first or second part-time job while in school, eager to try some of this ‘programming’ stuff in the real world.

Them: Somebody you're contemplating working for.
This: A list of questions you should ask to make sure this job is going to be a good fit.

Modeled after The Joel Test

Do you already have technical people on staff?
If you’ve never done web/mobile/whatever development before, being the first technical hire for a ‘business founder’ start-up is a mixed bag. Especially for your first experience, having a qualified technical mentor makes a big difference for how quickly you pick things up and whether you learn to do things ‘the right way’ the first time around or not. There’s a whole class of developers out there that have picked up PHP/Javascript from sketchy tutorials that get the job done but result in sloppy/outdated code.
Googling around is a great way to learn, but having a competent technical mentor point you to the right/best practice/reputable tutorials and explain things early on is the difference between having a piano teacher set your posture or a cursive teacher ensure your handwriting is legible early on.
Who is going to be working directly with you?
Before taking any job, meet the person you are going to be working with most directly and take them out for coffee.
Culture fit: Software engineering attracts all kinds of people; talking to your future potential mentor helps make sure that the two of you are going to be compatible. There’s absolutely nothing wrong with not being able to easily get along or fit with somebody, and you’d rather find out that you’re going to be the odd one out in a company now than have to deal with it for the rest of the semester.
Mentorship experience: Has your future mentor ever been a mentor before? It’s fine if they haven’t, but extra bonus points if they’ve gone through this process before. Alternately, it really helps if the mentor has ever themselves been technically mentored by somebody - they know first hand what it’s like to be in your shoes.
Ask: What worked well in your last technical mentor-mentee pairing? What kind of issues surprised your or would you want to change when we work together?
Eric, my boss for the past summer, started our first day at work by asking what I was hoping to get out of the internship. This stumped me for a good fifteen minutes; it was a fantastic question that helped crystallize our professional relationship and help us structure our work accordingly - “Alexey, you mentioned you had hoped to get more exposure across the stack. Do you want to work on the CSS for the new page we’re building?”
Will my code matter?
One of the greatest joys of writing code is seeing your code ship and run in the wild; having users benefit from your design decisions feels great. If at all possible, make sure the code you will be writing does that. There are (at least) two reasons it may not: internal software or dead software:
Internal: Joel Spolsky described the Five Worlds of Software Development almost a decade ago. Internal software doesn’t have to be well written or engineered; it is typically written quickly and then left to (hopefully) still work. There’s a ton of ‘internal’ or ‘good enough’ software in academia and start-ups, and being able to be good at writing prototypes or good-enough software is a useful skill; just make sure that it’s not all you ever do. At some point, make sure you get to work on code that needs to be great and not good enough; the amount you’ll learn about software engineering and code readability is drastically different.
Dead: Most start-ups fail; your code may never see the light of day. Even at big companies, one of my friends from this summer had her project cancelled half way through her internship for unrelated reasons. There’s no clear way to keep your code from being part of vaporware; the best that I can recommend is to follow your gut: does the project you’re considering joining seem like it’s going to happen with or without you, or is everybody living on a prayer?
Who had my job before?
If your potential employer has had interns before, ask to talk to them about their experience for a reference check. If a potential employer is trying to dodge the question of past experience, that’s a huge warning sign.
What are the expected outcomes of our work?
You’re looking for two types of outcomes: first, a particular set of skills through the job, and second, products that you can point to and say “I built that,” or “I built this part of that.”
Skills: What languages/frameworks/libraries are we going to be using? Do my mentor/boss/co-workers know these technologies well, or are we going to be picking a lot of them up as we go? There’s nothing wrong with having to pick up something new, (in general, most every project you do will probably involve learning to use a new library of some sort) but having somebody on the team with domain-specific experience helps. Make sure you understand what technical skill-set in particular you are going to pick up, and then check that the technology you are learning is the kind being used at the places you want to work. As of the time of writing this, I’d personally recommend picking up some of [Android/iOS development, Coffeescript, NodeJS Ruby, Ruby on Rails and/or Python].
Resume: One of your tasks as a CS graduate is to build a reasonable one-page resume/portfolio/github account showing off your credibility to potential employers for the summer or full-time. Be careful not to spend a year working on a project you can’t ever talk about.
Ask: is this work I will be able to point to online? Will I be able to show the source code to potential employers? Are there any parts of my work that I can open source and stick on my github profile? The answer will be ‘yes’ more often than you expect.
What is the format/schedule for this job?
There are a couple possible schedules for part-time jobs, from the very rigid (coming into the office on specific days and working set hours) to the very flexible (“can you get this done by next week?”). Which works best for you depends entirely on your schedule.
For me, having set hours for working part-time (but not full-time) has been a huge help. I’ve got enough things going on between classes, work and extracurriculars that if I don’t pencil in X hours a week for a particular activity, it’s unlikely to get done. Working in a specific location also helps place me focus and helps avoid everyday distractions. Plus, if you’re working for a start-up, they probably have free snacks. In terms of days for part-time work, I’d recommend either one or two weeknights or most of Friday.
That said, everybody is different. It may be that you’re able to get your work done in part-time chunks throughout the week. Regardless, make sure to speak to your potential employer about their propsed work schedule and try to understand their motivations. An answer like “oh, we’ll figure it out” is a useful warning sign that the potential employer hasn’t taken the time to think through how exactly your position will work.
How often will we have code reviews or pair programming?
If all you do is write code until it works and then submit it, there’s no real mentorship going on; you’re just a part-time employee. Mentorship means that you are getting feedback on your code consistently, if not for 100% of your check-ins then at least for a considerable fraction. Not every start-up can afford to do 100% code reviews the way that Microsoft, Google and Facebook can, but skimping on code reviews entirely is not acceptable.
Alternately, pair programming with your mentor means that you get to ask questions during your collaboration and absorb the kinds of little tips and tricks that are mostly passed down through apprenticeship. Best practices for pair programming as mentorship is worthy of its own blog post, but the one tip I’d have is make sure the mentee has the keyboard for the vast majority of the time.
Code reviews or pair programming; potentially both. If you’re getting neither, you’re not learning any more than you would be if you were working alone.
How will I be compensated for my work?
Programming work pays far better than most student on-campus jobs. Rates vary: I’ve seen lab work at as little as $8/hour, internships can go between $12-25/hour and your pay as a freelancer is bounded only by your imagination and what the market will bear.
That said, at this stage in your career I’d prioritize learning over compensation. Even at a relatively high salary, the fraction of your college loans that the internship will ever pay off is likely to be negligible. If your financial situation allows for it, I’d pick at least your first or second part-time job entirely based on how much better of a developer the job will make you, and worry about the money later. Even if your sole focus is financial gain, a solid but unpaid internship pushes your lifetime value forward far more than a well-paying dead-end part-time job.
The difference between a great and a mediocre job/internship is huge. I learned more in 3 months at Facebook than I did in 3 years as a software engineer in the Israeli Defense Forces.
On the flip side, the benefit of a paying job means that the company is invested in you.
What if they offer equity?
“Whatever they offer you, equity or salary, ask for the other one”
I can’t find the source of this quote, but it reasonably sums up the best practice here. The start-up is making a choice about compensation: whatever thing (equity or cash) they don’t give you is the thing they consider more valuable, and therefore the thing you should be more interested in obtaining.
I remember emailing a web-developer who was a mutual friend when I was starting out and offering to work together. All was well until I offered equity ‘as compensation’. I never heard back. Start-ups throwing around equity offers left and right in lieu of payment are a pretty good ‘tell’ for amateurishness, especially given how favorable the current climate is to entrepreneurs wishing to raise early-stage capital.
In general, I think I agree with my boss from this summer, who basically considers the equity component of his compensation to be the equivalent of a lottery ticket - nice to have, but not to be depended on.
There’s no hard and fast rule for whether to accept equity as early-stage payment or not, but ‘no’ is a pretty reasonable default. “Either pay me for my work or show me how I’m going to get mentorship from this position,” is not an unreasonable answer at all; don’t be afraid to use it. For the less confrontational, a simple “I’d love to work with you, but I’m on financial aid and need a steady income” is a completely reasonable excuse.

That’s what I’ve got. Am I missing anything? Let me know in the comments.

PS. Should I work for this startup I just met that can barely pay and only has business folk on it so far?

Maybe. Your goals for a part-time job should be to learn and to get paid, in that order. No technical people on staff means you’re going to have to pick everything up yourself. None or barely any payment other than equity means that you are effectively doing the work pro-bono. The question then becomes: is this a better opportunity for me than

Working on my own side projects, or
Taking a research position / alternate internship?

The answer is a maybe. If you are particularly passionate about the idea, or like me have a hard time focusing on side-projects that don’t have solid deadlines, and you can’t find an alternate position that lets you learn the same technology but get paid/receive mentorship, go for it.

PPS. Where do I look for awesome Mentorship opportunities at Penn/in the Philly area?

Here are the places I know about.

Penn:
- The Daily Pennsylvanian is looking for a couple of new faces. I’ve written about this before - the pay is terrible, the responsibility is great, it consumes you and a year later you come out having your shit together and go on to work for google or start a company.
- PennApps Labs, (which, in fairness, I’m affiliated with) just finished our mentee recruiting process. We’re not actively hiring right now, but feel free to shoot an email to labs at pennapps.com if you’re interested and let’s chat. We are comprised of former Facebook, Google and Amazon interns (amongst others) who care about student-run technology and the quality of our code.
- Coursekit is starting a Hacker House on campus. Dan and Jim, the technical founders, are competent and friendly like no other, and former CS TAs. I’m very, very excited to see how their program will go. Email dan at coursekit.com if the form doesn’t work for you.
Philly:
- Devnuts is a Northern Liberties hacker space, and home to Jarv.us. Again, I’ve written about (and helped) these guys before. They appear to have a very well thought-out internship process.
- Indy Hall is another co-working space, this time in Center City. A bunch of companies work out of there - I’d email their general ‘contact’ email and see who may be hiring.
- Gabriel Weinberg of DuckDuckGo fame already has one of our interns, and he wouldn't mind another. Gabriel is a solid hacker and, I imagine, a great mentor.

PPPS: You should follow me on twitter, check out my Intern's Guide to the Bay Area and maybe consider Hosting a Hackathon at your school (and/or come to ours).

Twelve apps to transform you into a more tech-savvy [Penn] student

2011-09-28T14:55:00-07:00

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

Fiesta.cc
Whenever working on a team project, there’s always that guy who forgets to reply-all — annoying, but not worth creating a Google Group for. Fiesta.cc is the best of both worlds — just email your collaborators and CC mktg101@fiesta.cc (or whatever name you want), and it creates a listserv for your team automagically.

ScheduleOnce
Everybody is busy, and scheduling sucks. ScheduleOnce pulls in participants’ Google Calendars to avoid the chain of emails around “Well, what about 3 p.m. on Thursday?” as well as the burden of manually entering every damn time you’re free next week on a Doodle.

QuickCite
Bibliographies were the bane of my existence when I took my writing seminar. Take a picture of a book’s ISBN code with your Android or iPhone and QuickCite will email you the citation, formatted according to MLA/APA/whatever guidelines you need.

Venmo
“It’s like your phone and your wallet had a beautiful baby.” Use your phone to pay your friends back when they cover you at a food cart. My friends and I use Venmo to split dinner, buy drinks and even pay utilities. Started by two 2005 Penn grads, Venmo has apps out for Android and iPhone, but text messages work as well. No commissions at any step of the process. It’s like PayPal, if PayPal didn’t suck.

...see the rest in the article here.

An Intern's Guide to a Summer in the Bay Area

2011-08-23T13:08:00-07:00

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.

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.

Realizing Rewards from your Hackathon Sponsorship

2011-07-30T18:10:00-07:00

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.

Fred Wilson

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.

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

Sure, let's be LinkedIn friends

2011-07-14T19:28:00-07:00

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.

Is Federated Social Networking going to happen?

2011-06-18T19:02:00-07:00

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.

Introducing: CIS@Penn Bloggers RSS/Twitter Account

2011-06-13T17:11:00-07:00

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.

Hosting Hackathons: The Organizer's Checklist

2011-06-03T02:18:13-07:00

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

Event Timing and Format: Figure out when you're going to have your hackathon and what the format is going to be like (12/24/48 hours, or some longer period like Columbia's DevFest).
Key Partners: Figure out what key groups from your university you're going to work with to get things done. We got a ton of support from the Student Government, our Innovation Center and the Provost's Office. You'll need these as proof of legitimacy for your website.
Funding Instrastructure: You also want to make sure you're all set up to take funding once it becomes available. We've found most companies are happy to either pay via Credit Cards or write us a check. Our organization (the Dining Philosophers, Penn's CS club) is University-affiliated, meaning all of our funding needed to be made out to the University. If this isn't the case for you, feel free to give something like KickStarter a try. Either way, reach out to your relevant University partners and make sure you've got a way to take money once it's available.
Design Standards: You're going to make t-shirts and print posters. To keep a reasonably consistent design standard, see if you can get your designer friend to contribute a logo that will work across various background colors and ideally a color scheme. Good design is a solid way to show legitimacy when asking for funding
Website: Put together a simple static website explaining what the hackathon is, who is organizing it, what you're hoping to do and what you need (hint:probably money). Your audience at this point are the sponsors - when you email them asking for funding.
For the first PennApps, we ended up writing a bunch of plain HTML and using the Posterous API to pull in blog content to the main page. The second time around, we used WordPress - this took away some of our design flexibility but made it far less painful to drop in new content. We're sticking with WordPress.
Location (ideally): if you're lucky, one of the Key Partners (above) will be able to help you find a location for the hackathon that works for you. More likely, you'll need to spend some amount of time reaching out to the University to try and see where you might be able to host the event. We wrote up a Location Requirements document to help streamline our conversations with the administration.

2-3 Months Before

Key Sponsors: Once you have a basic website and an idea for the event you're going to have, you're able to start reaching out to sponsors to get funding for your event. We started with high-profile sponsors with whom we had established relationships first, largely through internships. We reached out to Microsoft, Google and Facebook first; getting confirmations from those sponsors and being able to put them on our website made the rest of the sponsors easier to convince.
Blog Content: By no means is it necessary to have any blog content for your site, but I figured that between interviews with past participants and the rolling out of updates, a simple blog would be an easy way to make the site 'alive' and develop some early buzz amongst students.
Location: Try to have your location down by this point.

1-2 Months Before

Sponsors: The Key Sponsors are going to make your life easier in finding the rest of your funding. Make sure you've approached the funding sources suggested in an earlier post.
Judges: If you want awesome, important people to come serve as Judges for the demo session, you're going to need to ask them reasonably far in advance (at least a month would be nice).
Tech Talks: One of the fun things to do at Hackathons is try new APIs and frameworks. Start to figure out what companies or individuals in the area you want to reach out to to introduce the APIs before the hackathon. Developer Evangelists tend to be pretty high in demand (on the Android team in particular), so make sure to start this at least a month in advance and try to work out the talk schedule in a way that works for everybody.
Schedule: Start to put together a preliminary schedule for tech talks, the hacking itself, meals, and awards/prizes. This schedule will be bound to change, but having a first draft helps get judges/sponsors/tech-talkers give feedback and start to form their schedules around the event.
Website: Start addings sections on the website for the sponsors, judges, talks and the planned schedule (basically, each of the points above). If you're going with a blog, keep posting.

3 Weeks Before

T-Shirt Design: T-shirts matter. Come up with an awesome design and make sure to get yours made ahead of time, rather than rushed and therefore more expensive. Fewer colors is cheaper (add about $1/color/shirt). We used a local store but I've heard reasonable things about customink.
Outreach: Figure out who your attendees are going to be and how to find them. For Penn, emailing the relevant CS department list-servs and clubs on campus got the job done. Externally, we reached out through friends to invite hackers at other schools. Get people to sign up and commit to coming. We used a Google Form the first time around and EventBrite in January. Neither quite satisfied our needs (which is motivation for another post), but EventBrite isn't bad.
Location: In case you don't, you should REALLY have your location figured out by now.
Food: Compile a list of potential caterers for the event, doing your best to keep it varied, healthy, and cheap (we aimed at <$5/person/meal and only doing Pizza once). Go down the line and start contacting caterers to see if any of them are interested in providing food for free or at a deep discount in exchange for a sponsorship/recognition/etc (hey, it can't hurt to ask). Get prices and lead times (IE, if 20 more people than expected show up, how much in advance do I need to tell you by) and start working on a short-list.
Tech Talks: At this point, most of your tech talks should be solidified.
Local Sponsors: There's a category of local sponsors that should be able to give you stuff (Red Bull, stickers, schwag) that are worth reaching out to, but can be dealt with on a shorter time schedule. Note: some barter sponsors from larger companies may need several weeks to get things things approved within their companies - make sure to reach out to them in advance.

5 Days Before

Tech Talks: should be completely booked and know exactly when they are going. The finalized tech talk schedule should be up online and emailed out to participants
Participants Counts & Finalizing Orders: At this point, you should know approximately how many people are going to make it (so you can order T-shirts and food appropriately). I was off by more than 50% both times I tried to estimate the participant count for PennApps. Here's what I recommend: email everybody that has signed up about 5 days in advance and ask them to respond with 24 hours to confirm attendance. The number of people who have responded are a reasonably solid guess (something like 10-20% of even those people will have something come up, but yet others will end up inviting their friends, or somebody will hear about the event, etc).

The Day Before/During

Posters, Posters, Posters: Put signs everywhere. If you're within a couple of blocks of the event, you should be able to know how to get to it.
Event Logistics: Make sure the website is ready for the event. Figure out what your channels of communication are going to be throughout (Twitter? IRC back-channel?) and have links on the site. Figure out who the contact people are going to be for the event and create a Google Voice number that forwards to all of them. Put the number on the website.
Social Media: Somebody ought to be manning your Twitter account/taking photos and potentially video interviews throughout. Participants will have worked their ass off throughout the event and deserve to have evidence to show for it.
Back-up Plan: Things are going to go wrong day-of (out of power cords/need more food/X just broke) inevitably, spending money is going to be the fastest way to solve a lot of your problems. Make sure you know where that money is coming from and who is getting reimbursed for it, and how. Save receipts.

Post-Mortem

Demonstrate Results: Either host links to teams' work or (ideally) share the videos of their presentations. Teams (and the hackathon itself) need to be able to point to tangible results.
Promises to Keep: Whatever value proposition you made to sponsors, make sure you've kept up your side of the bargain. We send out emails to participants after the fact thanking and listing sponsors as well as making it easy for sponsors to recruit from participants.
Get Feedback and Iterate: Both from the sponsor, judge, and participant side of things, ask for feedback and take note of what kind of things can be different next time around.
Mark your success: The Hackathon organizers probably haven't slept in a while. Now would be a good time to buy them a drink.

Obligatory: we've just opened up sign-ups for PennApps 2011. If you're anywhere near the Philly Area this September, sign up for updates and we'll keep you in the loop.

Venmo Review: It's like your wallet and your phone had a beautiful baby

2011-05-17T14:00:00-07:00

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

Hosting Hackathons: The Team

2011-05-15T21:10:00-07:00

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.

Getting started with Web Development: what you need to know.

2011-04-30T09:59:00-07:00

[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:

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?

Dear Dr Stallman, the Aftermath

2011-04-24T14:00:00-07:00

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: An Open Letter

2011-04-21T16:13:00-07:00

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]

@Bluffn from HackNY

2011-04-12T08:18:00-07:00

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.

Permission Denied for chmod: Cygwin on Windows 7 doesn't play nice with files in Dropbox

2011-04-06T12:48:00-07:00

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.

Daily Deals: Everybody's favorite bubble

2011-04-04T12:43:00-07:00

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:

Cool Story, Bro: Haig and Jason from WineAccess.com

2011-03-25T12:08:00-07:00

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

Recruiting Penn Engineers Talk

2011-03-21T00:15:57-07:00

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:

Working with Penn Engineers for IMG [2011.3.19]

View more presentations from Alexey Komissarouk

The 'go' command

2011-03-15T15:13:00-07:00

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.

Recruiting Penn Engineers: A Case Study

2011-03-06T08:26:00-08:00

In http://alexeymk.com/recruiting-penn-engineers-intro-emails-that-d, I promised a case study. Here goes.

For a bit of background, John of Jarv.us was introduced by a mutual friend seeking advice on how to attract interns from Penn CS; I offered to help with his email copy with him if he didn't mind me publishing both versions. Thanks, John!

Before (264 words)

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

Comments
Actually, this email wasn't that bad to start with. It was a little bit longer that necessary and spent a bit of time on platitudes that every email seems to have "a job that challenges," "high-pace technical and intellectual environment," etc. The salary and exact needs were buried at the end of the email, and details about the company itself were missing. After going through a couple of drafts with John (and with the help of some friends), we ended up sending out the following

After (179 words; this was sent out)

Jarvus is a web and mobile development firm based in Philly looking to hire mobile developers part-time at $20-$35/hour, starting this semester. If you’ve been looking to improve (or pick up) Android or iPhone development skills, we provide a high-pace technical and intellectual environment that forces students to sink or swim. Students at Jarvus are expected to work 10-15 hours per week during the semester, meeting with their mentor on a weekly basis by travelling to our office in Northern Liberties (3rd and Poplar).

About us:
The Jarvus team is built on self-taught web developers who thrive on advancement. You’ll work directly with the development team and be expected to contribute during information architecture discussions and team meetings. We've worked with students from Drexel, Temple, UArts and others; most past interns have left Jarvus with several projects under their belt. Some of the apps past interns have worked on include TEDxPhilly.org, TheRoots.com, PhillyTechWeek.com, and ScienceLeadership.org.
If you’re interested and/or have any questions, drop me a line at john@devnuts.com

Comments
We (hopefully) did a number of things right here. First, the exact demands, structure and offer are right in the first few sentences - in Philly, $20-35, starting now, Android or iPhone, 10-15 hours a week, once a week meeting structure. This let students figure out right in the first couple of sentences whether the job could be a fit or not.

In the second paragraph, John quickly lists the benefits of working at Jarv.us/devnuts: they are experienced with interns , they are all self-taught themselves, and you get to 'own' an entire project. Finally, a more concise version of 'cool things people have built' is appended as part of the pargraph. The email ends on a personal and sincere note - "here's my email, I'm just some guy and I don't mind sharing it with you, feel free to ask questions".

All in all, the email becamse shorter, less grandiose, more precise, and more personal.

Hosting Hackathons: Getting Awesome Sponsors

2011-02-28T23:50:00-08:00

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.

Recruiting Penn Engineers: Getting intro emails right.

2011-02-12T13:53:00-08:00

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.

The Bay Area is Awesome

2011-02-08T16:23:00-08:00

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.

The recruiting email that wasn't

2011-01-28T07:15:00-08:00

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]

Technical Jobs on Campus: thedp.com

2011-01-28T05:51:00-08:00

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:

This is your chance. The Daily Pennsylvanian has openings in its Web Development Department this spring.
TheDP.com and its associate websites — 34st.com, eventsatpenn.com, and underthebutton.com — combine to generate over 25,000 pageviews per day and thousands of dollars in ad revenue. At the DP web department, you'll work with the most pervasive content-management systems on the web, such as Drupal and WordPress. We're looking forinnovative thinkers, both developers and designers, who have familiarity with HTML, CSS, and PHP.
If you're interested, e-mail Kyle Hardgrave at hardgrave@thedp.com for more information.

At The Daily Pennsylvanian, amazing stories start every day. Start yours today at thedp.com/join.

Source: cis-ugrad list-serv.

Pros: You're work on a website you and your friends use on a daily basis (maybe? hopefully?). It feels good. You learn a ton about doing web development reasonably right in a production environment.

Cons: The DP can take over your life. Also, the pay is terrible (either nothing or a couple of hundred bucks a month). Also, there's a good chance you'll have random business people who want you to do things like help create content for advertising.

Counter-Cons: There's nothing wrong with things taking over your life, so long as they're good things. Also, the DP is a large and tight-knit community that puts together an award-winning newspaper. So there's that.

Good for: Freshmen/sophomores and anybody looking to learn/get into web development but preferring a formal structure.

How I know: Dan Getelman ran the DP website starting spring of his freshman year. He turned out all right.

Product Design Ideas from OPIM 415

2011-01-24T22:05:00-08:00

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?

Too cool for tungle.me?

2011-01-22T10:40:00-08:00

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.

Loose Ties Link Ships: Friending norms on LinkedIn

2010-12-31T22:25:00-08:00

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?

Recruiting Penn Engineers: Who we are, how to reach us

2010-12-28T07:56:00-08:00

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.

Flipping Coins through Mechanical Turk: Part 2

2010-12-19T08:45:00-08:00

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?

Flipping Coins through Mechanical Turk: Part 1

2010-12-18T10:42:00-08:00

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.

xs:anyURI requires ampersands to be escaped

2010-11-28T14:42:00-08:00

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

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 & (IE, www.yoursite.com/mturk/a.php?foo=true&bar=false).

That'll fix it.

Reference:

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

.h file generator

2010-11-02T04:33:00-07:00

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:

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

Rewrite as shell or python script. Switching from vim commands to python is probably going to add some flexibility.
Incorporate the script directly into a Makefile. In this scenario, make will depend on header files being re-generated, and only then call GCC.
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?

First! (also, a placeholder)

2010-10-03T13:51:00-07:00

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.

Alexey needs a web presence

Statistical Significance on a Shoestring Budget

Part 1: Do we have the numbers?

Part 2: Boosters

Bigger Bets: combine ideas together, merging by theme

Best Foot Forward: Use fewer variants, A/B/C/D become A/B

Run in Parallel: A/B/C/D becomes A/B, A/C, and A/D

Share Components on High-Throughput Surface Areas

Run tests for longer: 7 days becomes 2-3 weeks

Get Comfortable with False Positives: p<0.05 becomes p<0.2

Buy Traffic

Part 3: Desperate Times

Target a Proxy Metric

Run your Tests on the Paid Layer

Go Qualitative with Surveys, Paid Feedback and Session Recording

1. Use a tool like hotjar.com

2. Pay testers

3. Use screen recording tools

YOLO - Just Make the Change

There's no such thing as Organic Traffic

What’s the big deal, you pedant?

OK but for real, these customers did come from organic search

Fixing “Organic Search”

Simplest: spread evenly across known channels

Slightly better: Incorporate How did you hear about us? (HDYHAU)

Fancy: Marketing Mix Modeling

PS. Only getting harder over time

Hamtips, or why I still run the Technical Phone Screen as the Hiring Manager

What is the HMTPS

Why combine the two interviews?

Why 75 minutes?

TPS (60m)

HM call (30m)

HMTPS (75m)

Why is this good for the Hiring Manager?

Why is this good for the candidate?

When is this a bad idea?

A toolset for tackling technical debt

The Situation

How did it get this bad?

So what did you do?

Tackling Technical Debt In Three Easy Steps

Step 1. Empower

Step 2. Identify

Step 3. Prioritize

Getting Buy-in

Tackling Small Debt

Tackling Heavy Debt

So what happened?

Technical Interview Superforcasters

Introducing: the Phone Screen Team

Why did you think this would be a good idea?

Starting your own Phone Screen Team

1. Identifying Interviewers (footnote 5)

2. Logistics & Scheduling

3. Onboarding Interviewers

4. Continuous Improvement

5. Retention

Conclusion

FAQs, Caveats, and Pre-emptive Defensiveness

Lies, Damned Lies, and Front-end Tracking

Part 1: A Cautionary Tale

What happened?

How bounces work

Part 2: How we fixed bounces

Part 3: Front-end tracking done right

1. Performance

2. Fidelity

3. Powerlessness

What should i do instead?

FAQs & Caveats

Does your approach break identifying & cookie-ing users, so you can retarget effectively?

I heard server-side conversion tracking for google and facebook doesn’t perform as well.

The End.

Lessons Learned: Giving Feedback as an Engineering Manager

Feedback budgets

Change the template, change the world

Process linters

Happy Ending

The Appendices Three