Aseem Kishore - Blog

Hello, Pomelo

2022-10-02T00:00:00+00:00

(Originally published on Substack. Subscribe there for email updates!)

I’m excited to share that earlier this year, I joined an early-stage startup named Pomelo as VP of Engineering — and we just launched!

Pomelo as a product and idea is brilliant. But first, some background.

Millions of immigrants live in the US and regularly send money back home to their families. These money transfers, called “remittances”, total ~$150B per year from the US alone.¹ 🤯

To send money home today, immigrants have to use traditional remittance services, which charge hefty transfer fees and exchange rate markups. The World Bank and the UN have found that remitters lose 6-7% — that’s ~$10B/year! — to these costs.² 😰

Some immigrants even physically carry large amounts of cash back home, e.g. using backpacks with false compartments, to save on these costs. (I’ve now learned that multiple people in my own network do this!)

Enter Pomelo. We just launched a whole new way for immigrants to share money with their families back home — for a fraction of the cost.

We do this using the power of credit. Instead of sending cash overseas, our Pomelo Card™ lets remitters share access to credit. Specifically:

Remitters sign up for our Pomelo Card here in the US. We offer both “secured” and “unsecured” cards, so everyone can qualify, regardless of credit history or income.³ (This makes us a great way for immigrants to build credit in the US!)
Remitters then add their families abroad as authorized users on their cards. Remitters can set fine-grained spending limits per family member and pause/unpause cards at any time.
Their families use their cards to pay for expenses (like groceries, dining, and online shopping) anywhere that Mastercard is accepted. We both mail physical cards abroad and provide instant “virtual” cards for mobile and online use.
Remitters pay the bill here in the US. They also pay only after any money has been spent, not before. This protects both remitters and their families against theft, fraud, and other unauthorized use — which cash can’t do.

This works similarly to adding authorized users to your credit cards here in the US, but we’ve done the work to (a) enable this internationally, (b) eliminate transfer and transaction fees, and (c) provide one of the best exchange rates on the market today.⁴

Finally, the way we make most of our money (like most credit cards) is through interchange: instead of charging our customers fees, merchants and banks pay us a portion of every transaction. This puts money — hopefully billions of dollars one day! — back into the hands of remitters and their families who need it most.

The result: instead of sending $500 home in cash every month for up to $35 each time, remitters can now share $500 in credit — with safety, transparency, and control — for just $1 today.⁵ 🤩

This idea sounds simple, and — like many great ideas in hindsight — it is. But it’s required a lot of “schlep work” to make it real, like signing key business partnerships, setting up proper compliance programs and controls, and building several new technical integrations that have never existed before.

I’m excited by this combination of a simple idea in theory that’s non-trivial to execute in practice.

The credit for the idea goes, of course, to our visionary founder and CEO, Eric Frenkiel. If you’re interested in learning more about his founding story and our broader vision, check out his own launch blog post and this TV interview of him:

What energizes me most, though, isn’t just the idea — it’s the concrete customer feedback we’re getting. We just launched in the Philippines, and these are real customer quotes from our early adopters so far:

We even have our first customer unboxing video now! 😃

View this post on Instagram

A post shared by Scott G Drury (@mistercmt)

And we’re seeing traction through quantitative data, too. This is a chart of our total transaction volume (after months of hard work on our funnel and fulfillment), and many of our other key metrics are starting to look like this now, too.

We still have so much more to figure out and build and improve, but it feels extremely energizing to be building something that’s both so helpful to our customers and so loved by them. ❤️

There’s so much more here that I want to say about why else I joined and what else energizes me here. I’ll distill this to three more points:

The team. I have excellent colleagues who are not just capable, but also kind and hard-working. They also bring awesome and varied experience:
1. Eric and our CFO previously built and grew another startup together that’s now worth >$1B.
2. Our VP of Marketing was employee #8 at Remitly — another company in our space that IPO’ed at $7B last year — and is Filipino himself!
3. Our VP of Product helped grow Affirm (as did our customer service lead), and shipped things millions of people still use at Twitter and Google before that.
4. Our Chief Compliance Officer was also CCO at the startup that ultimately built the Apple Card.
5. (We may have also just hired a lead designer from a well-known and well-loved neobank… but I don’t want to steal his thunder. 😉)
The culture. I now seek companies that value both the “what” and the “how”. I want to achieve real, lasting impact and also love the journey along the way. The “how” that we value is holding ourselves to a high quality bar; being open to mistakes but committed to learning from them; hiring great people who aren’t just talented but also collaborative and empathetic; working as a team rather than as individuals; giving feedback directly and kindly, and receiving it graciously. Perhaps most notable to me is our passionate customer focus, where we broadcast real customer comments almost every day, and our full-company transparency, where we proactively and openly share almost everything.
The work. We’re building something that’s never existed before, and we’re just getting started. We have to solve unique product problems, like conveying the nuances of charge cards to customers that have never encountered them before. We have to solve business and technical problems, like enabling frictionless UX and immediate delight without compromising on security or fraud. And we have to build an excellent company along the way to keep succeeding as we grow and scale. Work like this is why people join startups. I love having the opportunity to do that here, thanks to our traction and potential.

In each of my previous three startup experiences, I took something unique and valuable away. When I was looking for my next role, I really wanted to find a company that could bring those things together.

I wanted first and foremost to find a great, socially positive mission. (I really want to have a lasting positive impact on society.)

I wanted to find a company that had clear business potential. (I believe that building a big, sustainable business with the right, aligned incentives can be a great way to maximize that positive social impact.)

And I wanted to find a company that’d also be a great place to work (where I’d love the team and culture and work every day).

I was very excited to find this combination in Pomelo — and that’s why I joined.

Our early traction is now a cherry on top, and I’m pumped for our opportunity ahead.

If you’re as energized as me by everything above, I’m excited to announce that we’re hiring now! 🎉

We’re particularly excited to hire 3-4 more engineers over the next few months. Follow that link to learn more about our tech stack and what we’re looking for.

We’re fortunate to be in a recession-resistant industry, where remitters send even more money home during recessions.⁶ (Remittances aren’t frivolous expenses; their families are relying on the funds to live.) So unlike many companies today, our business is rapidly growing, not shrinking.

We’re also fortunate to be well-funded. Our two most notable investors to me are Kevin Hartz and Keith Rabois: Kevin co-founded Xoom, one of the most popular remittance services today, and Keith served on the board of Xoom. I love the expertise they bring in our space, and I’m excited that they (continue to) bet on Pomelo.

So while many other startups are contracting and preparing for a fundraising winter, we’re expanding and preparing for the winter holidays — the peak remittance season of the year. This is literally a great time to join us. 😎

—

Thanks for reading! If you have any questions about Pomelo, reach out. And if you or anyone you know sends money home to the Philippines, give us a try! I’d love to hear your experience and feedback.

I’m excited for us to achieve the impact we want to achieve, and I look forward to sharing more of our progress along the way. 😃

Sources: Center for Immigration Studies, Forbes ↩
Sources: World Bank, UN ↩
We of course reject suspected fraud, and we may change our requirements to qualify in the future. Banking services are provided by Coastal Community Bank, Member FDIC, and are subject to the terms of our Cardholder Agreement. The Pomelo Card is issued by Coastal Community Bank pursuant to a license from Mastercard International and may be used everywhere Mastercard is accepted. Pomelo, Inc. is a technology services provider and the administrator of the card program. ↩
We publish and keep up-to-date a comparison of our and our competitors’ exchange rates on our website. ↩
This $1 comes from a 0.2% exchange rate markup charged by Mastercard today. This cost may change over time! ↩
A powerful example of this was when the pandemic started in 2020. The World Bank predicted that remittances would decrease 20%, but they actually held steady in most cases and even increased 10% in some cases (e.g. to Mexico)! Source: The Conversation ↩

“Ignore the f’ing haters!”

2022-08-07T00:00:00+00:00

(Originally published on Substack. Subscribe there for email updates!)

Ten years ago, on Memorial Day 2012, I authored JSON5, an open-source project that aimed to fix a small problem I felt when writing certain software.

I’d been chewing on the problem for a year when I decided to finally address it. I coded for roughly ten hours that day, then shared what I built to Hacker News (a forum for software engineers) that night. This was the response I got:

Even Mitchell Hashimoto, creator of an industry-changing open-source project himself (and eventually a billion-dollar company as well), piled on. But he went even further: Mitchell took the time to make a parody project of JSON5 (it was genuinely funny, at least 😛), even making fun of me by name. He’s since deleted the project, but the Internet Archive has it here:

This was especially fascinating to me given that Mitchell Hashimoto was a creator himself — a “man in the arena”, not a critic on the sideline — and yet he went to such depths to express his dislike for my project.

I wasn’t upset or offended by any of this. I was mainly just surprised and shell-shocked.

The problem I’d set out to solve seemed so clear. I’d even credited others who had written about this problem before. And yet so many comments disagreed with me that this problem was even real, much less worth solving.

Fortunately, I ignored these comments and just kept building. I got some traction, which attracted others. And with others’ (significant) contributions and leadership, JSON5 slowly flourished.

JSON5 now gets >60M downloads/week, ranks in the top 0.1% of the most depended-upon packages on npm¹, and has been adopted by major projects like Chromium, Next.js, Babel, Retool, WebStorm, and more. All adoption has been entirely organic, with no company or marketing behind it.

My favorite example is that even Apple has adopted it now, supporting it natively across all their platforms! 🤯 This means that every iPhone and Mac now ships with JSON5 built in. I never even considered this to be a possibility and would have bet against it.

These results are in such stark contrast to the reception I originally got. So what gives?

I take three lessons from this experience that I’d love to share now, ten years later.

Lesson 1: Ignore the haters

This one is obvious, and I admit I enjoyed proving the haters wrong. 😛

But there’s nuance here, and some notable implications.

For starters, the reception I got wasn’t unique to me; it was standard for Hacker News and cliché across cynical communities. The canonical examples here are Drew Houston’s original Dropbox demo and Slashdot’s original iPod announcement:

But there’s something to be said about actually listening to feedback and criticism, and not just blindly building in a vacuum, ignoring the world around you, right?

The key difference to me is to know your audience/customer/market, and listen to them. Linux hackers weren’t Dropbox’s target market, nor the iPod’s. It turns out that all of the various software engineers on Hacker News weren’t my target market, either; specifically JavaScript engineers were.

So when I also shared JSON5 on the Node.js mailing list, the reception was notably more positive:

(Even Ryan Dahl, creator of Node.js, chimed in with praise… just two years later. 😂)

This was who mattered, so this was the feedback I considered and the validation that kept me going.

This lesson applies broadly.

One of my all-time favorite articles on building startups is this one from Rahul Vohra, founder of Superhuman, on finding product-market fit. (It’s a brilliant article and I can’t recommend it enough; take the time to read it if it’s relevant to you.) Rahul’s advice is all about listening to customer feedback, and even so, he specifically says to ignore the feedback of users who find your product entirely unappealing:

This batch of… users should not impact your product strategy in any way. They’ll request distracting features, present ill-fitting use cases and probably be very vocal, all before they churn out and leave you with a mangled, muddled roadmap. As surprising or painful as it may seem, don’t act on their feedback — it will lead you astray on your quest for product/market fit.

[These users] are so far from loving you that they are essentially a lost cause.

Just remember to still make something that some people love. One way to do that, as Paul Graham writes, is to simply make something that you yourself would want and love. I got lucky in that regard with JSON5. 🙂

I mentioned above that JSON5’s success owes in large part to others’ contributions and leadership. That wasn’t hyperbole — others really deserve much of the credit.

I’m grateful to Max Nanasy and Andrew Eisenberg for their significant contributions, and I’m especially grateful to Jordan Tucker, who took JSON5 to a whole new level. Jordan has contributed more code at this point than even me by an order of magnitude:

But what really keeps blowing me away isn’t the quantity of Jordan’s contributions — it’s the quality. Jordan elevated JSON5 from a little toy project to a truly professional-grade standard and ecosystem. He authored an actual formal spec, prototyped several more reference implementations, and even designed a beautiful vector logo:

Jordan’s also an amazing maintainer for the project. He consistently responds to every question, bug report, and contribution both more quickly and much better than I can. He thoroughly internalized the vision for the project, and he consistently upholds that vision and its principles. Most importantly, Jordan always represents the project — and speaks for the both of us — with an ideal combination of knowledgeable authority and kind empathy.

I can confidently say that JSON5’s adoption would be nowhere near what it is today if it weren’t for Jordan’s fantastic leadership and ownership.

So I don’t deserve all the credit, but I think I did at least two things right. 😛

I shipped early. Shipping less earlier allowed others to contribute more — and better than I could have myself.
I shared my legos. I truly gave up full and direct control, and this allowed JSON5 to flourish.

Sharing legos here didn’t come naturally or trivially to me. A lot of people wanted a lot of different things from JSON5, and I was pretty sure that the project would only succeed if it maintained focus. I felt responsibility to uphold that focus, so of course I should maintain control, right?

I was inspired here by this post from prolific open-source developer Felix Geisendörfer on a simple “collaboration hack”:

Whenever somebody sends you a pull request, give them commit access to your project.

This sounded crazy at first, but his reasoning and results were spot on. Like Felix, I was often too busy to manage contributions and review code in a timely manner. (I had a demanding day job, too!) And the most significant contributions often needed the most time to properly review and accept. So of course episodes like this happened, where I left a contributor hanging for nine months:

This case pushed me over the edge, and I decided to give Felix’s suggestion a try:

And just like Felix said, the results spoke for themselves.

Within a few hours the same person who had just submitted a rather mediocre patch, had now fixed things up and committed them. This was highly unusual, so I started using the same strategy for a few other small projects… And it worked, over and over again.

Initially I was very worried about giving up control over these projects, but the results speak for themselves. Both projects are now maintained by a bunch of amazing developers, writing much better code than I ever received in the form of pull requests before.

Felix explains this phenomenon much better I can, so I’ll just quote him here:

So why does it work? Well, I have a few ideas. Once people have commit access, they are no longer worried that their patch might go unmerged. They now have the power to commit it themselves, causing them to put much more work into it. Doing the actual commit/push also changes their sense of ownership. Instead of handing over a diff to somebody else, they are now part of the project, owning a small part of it.

Attracting great people you can trust and giving them true ownership is a powerful leadership lesson I’ve learned (on both sides) throughout my career.

A related leadership lesson is to inform and inspire. I love Netflix’s “context, not control” value and this advice derived from Antoine de Saint-Exupéry:

If you want to build a ship, don’t drum up the people to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.

This is a topic I want to write more about on its own. For now, I’ll end this lesson by summarizing:

Give up control. Share your legos. Benefit from more Jordans. 🤩

The future is crazy hard to predict. That’s doubly so with new ideas.

When an idea is new, it’s not only difficult to know whether it’ll succeed — it’s also easy to assume that it won’t.

As Jony Ive said so eloquently in his eulogy for Steve Jobs:

You see, I think [Steve] better than anyone understood that while ideas ultimately can be so powerful, they begin as fragile, barely formed thoughts — so easily missed, so easily compromised, so easily just squished.

I look back on Mitchell Hashimoto’s example as a fascinating case study here. Mitchell is and was an expert programmer and amazing technologist, and even he failed to see the value here. That makes sense in hindsight given that Mitchell’s background was more with Ruby and YAML than with JavaScript and JSON — but that’s the point. We’re all blind and touching different parts of the elephant.

Successful investors know this well. Paul Buchheit, creator of Gmail and partner at Y Combinator, made this point elegantly in a 2007 post: it’s easy to dismiss new ideas and be right most of the time — but if you want to be successful as an investor, it’s better to be optimistic and wrong most of the time, since the most successful ideas yield disproportionate returns. Hence, most successful investors approach new ideas with openness, curiosity, and humility, even if they still ultimately reject them.

(An example of Paul’s success with this philosophy was Twitch, which started as Justin Kan simply streaming his life 24/7, but which is now one of the most popular sites on the web. Paul expanded on this example and others in his wonderful 2014 Startup School talk — highly recommend reading. Other classic examples here include Airbnb and Uber/Lyft; “you’re asking people to let strangers do what??”)

But this isn’t just about our own self-interests — it’s also about the impact we have on others.

It’s taken me a long time to say this, but I believe that several of the initial responses I got crossed the line from disagreeing about an idea to being unkind. And this included Mitchell’s parody project — even though it was funny.

I feel fortunate and privileged that I wasn’t deterred. Due to whatever combination of nature and nurture I was brought up with, I maintained my conviction. But not everyone is so lucky or secure — and it’d be a shame to put those people down.

Heather Arthur, another open-source creator, wrote about her own experience being ridiculed for her work in this powerful post from 2013:

It seemed liked I’d done something fundamentally wrong, so stupid that it flabbergasts someone… So of course I start sobbing.

Then I see these people’s follower count, and I sob harder.

Heather fortunately turned out okay, as did I. But she had the same thought:

I evangelize open source whenever I meet new coders or go to meetups. I tell them to make something that they would find useful and put it out there. Can you imagine if one of these new open sourcerers took my advice and got this response without the support I had? Can you imagine?

I reached out to Mitchell as part of writing this post (my first ever interaction directly with him) to let him know I’d be referencing his project. Given that he deleted it some time ago, I assumed he regretted it in retrospect, and I harbored no grudge or ill will towards him. We all make mistakes and do things we’re not proud of sometimes.

Mitchell confirmed this assumption to be true and offered a genuine, sincere apology. Thank you, Mitchell — I appreciated that a lot. ❤️

Learn from Mitchell’s example, and Corey Haines’ and Steve Klabnik’s in Heather’s case. Be aware of the impact of your words and actions, and (especially if you have standing in your community) lift others up rather than push them down.

Let me end with two closing quotes from Ratatouille (I love this scene):

The world is often unkind to new talent, new creations. The new needs friends.

Not everyone can become a great artist; but a great artist can come from anywhere.

And this one from Ted Lasso (not Walt Whitman 😛):

Be curious, not judgmental.

Great ideas can come from anyone, and we’re all blind — so let’s be kind.

If you enjoyed this post, subscribe by email for more:

As of June 2022, the npm registry has roughly 2M packages, and JSON5 is in the top 500 by both dependents and PageRank. I haven’t been able to find package rankings by downloads anywhere, but would love to know that, too! ↩

Abortion, women's rights, and the role of men

2022-06-25T00:00:00+00:00

I just posted that I’m going to write about engineering leadership and management on this blog. In the wake of yesterday’s news, it feels disingenuous to truck ahead on that topic when so many are so impacted. I value being authentic, and I feel compelled to speak.

(I’m also inspired by leaders like Linda Kim who’ve courageously spoken up here even when they know it’d be far safer not to.)

I know abortion is a divisive topic. I try hard to understand others’ perspectives, and this topic is no exception. I view the divide between pro-life and pro-choice as mainly a difference in our shared values — the things we give more weight to than others. (I can’t wait to write about values and decision-making in the context of work.) I don’t pretend that I can change others’ values, and I don’t like to project or impose my own values onto others.

And yet, I’d like to speak, because I believe I have something helpful to contribute. I’d specifically like to talk about a point which I don’t see discussed. It might not change anyone’s values, but I hope it builds empathy and helps bridge a gap.

I read a post years ago that I can’t find now, but really wish I could. I’d like to give credit to the author (a woman), so if this rings a bell, please let me know.

The post made a simple point:

Every unwanted pregnancy is caused, at least in part, by a man. Pregnancy requires sperm, and men provide that sperm.

Contraception not used? The man could have used a condom, or pulled out sooner, but didn’t.

Believe two consenting adults shouldn’t have sex if they’re not ready to have kids? The man could have abstained, but chose not to.

And of course, there’s rape.

(As with all generalities, there’s nuance here. I’m focusing on the general point.)

What a simple and obvious point, but (at least to me) so profound and powerful.

So much of the conversation on the topic of abortion centers around women’s role and responsibilities. Use contraception; don’t have sex if you’re not ready for kids; don’t drink more than you can handle; don’t dress provocatively if you don’t want the attention.

We tell women to be responsible for the consequences of their actions — but it’s not just their actions.

When we focus only on women and ignore the role of men, we villainize women and absolve men. That isn’t fair or right.

The point here isn’t to blame men or argue that we should punish them, too.

The point is to give women more support and empathy than we currently do. They don’t become pregnant on their own, but their bodies certainly experience pregnancy on their own.

I can’t begin to fathom or truly empathize with the physical, mental, or emotional experience of being pregnant. But I can empathize with — and would be horrified at — having to go through that experience when I neither wanted nor caused it on my own.

There are a host of reasons why I believe in a woman’s right to choose, and I acknowledge I value things differently than those who don’t. I found this point particularly powerful, though, and hope it helps bridge our gaps at least a little.

Writing more

2022-06-20T00:00:00+00:00

Last year, I left one startup named Even to lead all of engineering at another startup named Cardless. I never ended up writing about it, but this was another valuable experience full of learning and growth.

This was my first time at this level of role (Head of Eng), and I made plenty of mistakes. With help and support from excellent advisors (Gil Shklarski), mentors (Nicholas Clark), coaches (Michael Langer), colleagues (James Paek), and especially my manager and Cardless CEO Scott Kazmierowicz, I learned and grew through those mistakes. And in the end, I hope and believe that I managed to deliver some decent value. 🤞🏽🙂

I’m tremendously grateful to those folx for helping me grow and to the Cardless team for the opportunity. Thank you all!

I left Cardless this past month to lead all of engineering at another startup. I’m excited to share more here, too, but for over a year now, I’ve also been thinking of writing and sharing more content around engineering leadership and management in general.

In preparation for my role at Cardless, and again in preparation for my next role now, I’ve read and devoured books and articles from the likes of Will Larson, Camille Fournier, and many other brilliant minds. I simply love this stuff and want to be the best leader I can be — to help any organization I work for be the best and most well-run it can be.

But when it comes to writing, I’ve never felt that I have anything particularly novel or unique to contribute. I’m just repeating what those others have already said (particularly Will Larson; he’s just so dang good).

I’m now feeling like I should still write and share, for three reasons:

I’ve been reading and loving regular posts from leaders like Waseem Daher and Aki Taha. Their content probably also isn’t breakthrough or novel, but it doesn’t need to be. They simply communicate powerful ideas elegantly, and those ideas resonate. Their posts help crystallize my own thinking — and that’s the point.
I’ve trained and coached new managers a few times now, and each of those times, I’ve found myself sharing lists of articles and ideas that I’ve found powerful. Even if I’m just repeating what others have said, the content is still new for those folx. And that’s also the point: this content can still help others — just like it’s helped me.
I have some first-hand, real-world experience now, and I’ve formed my own point of view. Ideas that were once abstract and theoretical for me are now more concrete. Hopefully my lived experiences can help others, too. (And hopefully I even get feedback that helps me, too!)

So I’m going to try and actually write and share content now, even if that content feels “basic”. I’m excited to start!

I’ll keep posting here and sharing on LinkedIn, Twitter, and Facebook, but if you’re excited to follow along, sign up here to get each post by email, too. (This’ll be low-volume — probably only once or twice a month.)

Feedback always welcome. Thanks all! Let’s do this. 💪🏽 🚀

Farewell, Even

2021-04-26T00:00:00+00:00

I joined Even in 2017, compelled by the mission and impressed by the founders. I thought I was putting my career on the backburner, not expecting to learn or grow too much, but boy, was I wrong. Over four years, I learned & grew more than I ever expected, as an engineer, manager, leader, and teammate.

I left Even this month for another opportunity (which I’ll share more about soon). Below is an excerpt of the note I shared internally to express my gratitude.

Dear Even,

As announced in Q&A today, I’m very sad to say that I’m leaving Even. 😢

I never expected to write this so soon! I wasn’t looking to leave — I love everything here from our mission and our culture to my day-to-day work and especially all of you. We’re also perhaps the best set up for success now, with David, Sam, and Preston now on board, than we’ve ever been before. An opportunity just came up for my own personal growth that I ultimately didn’t want to say no to.

I can’t express enough gratitude to all of you for how fulfilling you all made these 4 years for me. I especially want to thank Jon, Quinten, Ryan, and Jenny for building something so special and letting me be a part of it, Olivia & Will for being such high-caliber peers to work alongside & learn from, every member of my team who gave me the privilege of leading them, and every other engineer & Evener whom I had the pleasure of working or partnering with.

But I especially want to thank Evan. Evan has consistently been both one of my biggest supporters and one of my most challenging critics. He never hesitated to praise & thank me for what I did well, but also never hesitated to push me to do & be better. And even when his feedback was uncomfortable, it was usually valid — and it was always thoughtful and well-intentioned. Most importantly, he gave me so much opportunity to thrive, through ownership, sponsorship, and mentorship, for which I’m so grateful. I’ve learned & grown way more at Even than I ever expected to — and that’s in largest part thanks to Evan. Thank you, Evan.

The opportunity that I’m leaving for is to lead all of engineering at another (earlier-stage) startup, so I’ve been doing a lot of reflecting on my lessons learned at Even and what I want to take from my experience here and bring there. I’ve already written >50 lines of notes, and every day I keep adding more. Even has set a high bar, and I’m both so inspired and so daunted by that bar. I can only hope to create something as special as this.

So thank you all again. I wish you all an amazing next chapter, and I hope we all get to cross paths again. ❤️

How we interview engineers at Even

2020-08-06T00:00:00+00:00

This is a cross-post of a post I wrote at Even. Original post on Even’s blog.

Tech interviewing sucks.

As a candidate, it’s stressful, exhausting, and demoralizing. To do well, you often need to explicitly prepare, which is both tedious and time consuming. It may not even be feasible if you’re a parent or have other obligations outside of work. Interviews themselves can feel arbitrary and confounding. In the worst cases, you may not even know what your interviewers are looking for or whether you’re providing it.

Interviewing isn’t great for companies, either. Sourcing, screening, and interviewing candidates is endless work that takes significant time and energy, not just for the hiring manager but also for the team. Hiring decisions must be made after only hours of interaction, yet can have impact that lasts months or years. It sucks turning good candidates away, and it sucks making the opposite mistake.

How much interviewing sucks at any individual company, though, depends a lot on that company’s process.

At Even, we’ve put a lot of thought, care, and iterations into our own interview process. I’m proud that we now get both meaningful signal and consistent, positive feedback from candidates on their interview experience — even fully remote now — like this note from a candidate earlier this year:

“I was so impressed with the team members whom I met during the interview process. It was clear throughout that the care you are taking in selecting for values and behavior is to good effect. I also appreciated that the technical interviews were both engaging and humane.”

In this post, I’m excited to share the details of our interview process and how we arrived at it. I hope this is helpful to both candidates and other companies.

First, our context and philosophy

We aren’t the first company to write about interviewing. There are a lot of other admirable companies and people who’ve been pushing to make our industry better for a long time. Joel Spolsky, Honeycomb, and Triplebyte are just a few examples I appreciate that have informed our process.

When reading any advice, though — including this post — don’t apply it blindly. Consider the context and how it may differ for you.

Here’s our context:

We’re a fiscally responsible startup. That means we have a small team and limited seats, so our hiring decisions matter a lot.
We have a strong social mission. We’re tackling a large, important problem and demonstrating clear, meaningful impact. This helps us both attract and retain great, mission-aligned engineers more effectively than a company of our size may otherwise.
Our onboarding takes time. We’re not a simple CRUD app. Our domain is complex (we deal with real-world money movement, sensitive financial data at scale, and important security, privacy, and regulatory concerns). Our codebase is large (>500k LOC today). And much of our tech is new (e.g. Go, GraphQL, and React Native). These things take time to learn, but we commit to providing that time. We love investing up front in our engineers like this because we see the compounding dividends this yields. In return, we accept taking a bit more time before deciding that someone isn’t a good match.

Given this context, we’ve found that hiring someone who isn’t a good match is a much worse mistake for us than turning someone away who may have been. This realization has led us to one key decision: We optimize for reducing false positives today.

This decision has ripple effects on other important factors for us. If we want to be selective in our hiring, we need to interview many candidates. To interview many candidates, we need to keep drop-off low throughout our funnel. To keep drop-off low, we need to minimize delays in our process. To minimize delays, we need to spread interviews out across our team. Finally, to have confidence in the assessments we get across our team — as well as to combat unconscious bias and build a diverse team — we need to standardize our interviews as much as reasonably possible.

“If I ran a company, that’s exactly how I would want the interview process formulated. It’s nice to know that with a thorough interview process like this, Even will keep hiring good people, and selfishly, those are the kinds of people I want to work with.”

These factors have played an important role in the decisions we’ve made below.

What we don’t do

For starters, we don’t do…

Whiteboard coding
Riddles and brain teasers
Trivia/memorization questions

I won’t dive too deep here. These things are commonly understood to provide noisy signals at best, and we agree.

But we also avoid other things that can be good and that we ourselves have done in the past. This is where our context and philosophy comes into play.

Today, we don’t:

Ask candidates to do a take-home project. I personally feel no doubt that take-home projects provide some of the best insight on real-world ability, and we’ve experimented with them in the past. Unfortunately, there are too many candidates who either can’t or won’t make time for these, so the drop-off ends up being too high for us to accept. (We may experiment with giving candidates a choice here in the future, but that would also make our process less standard across candidates.)
Ask candidates to give a tech talk on a past project or topic of their choice. We experimented with this previously too, and I personally really like the idea of letting candidates teach us in their area of expertise. But because both the content and the style of talks vary so dramatically across candidates, we found it very hard to standardize our assessments across interviews. This left us little confidence in the correctness of our decisions.
Ask candidates to show us a code sample (whether asynchronously or via a live code walkthrough). We did this in the past, too, but the massive variety here also made it hard to standardize our assessments.
Ask candidates deep algorithmic questions. Triplebyte makes some good arguments for why they can be good, but the main downside is clear: Plenty of great engineers struggle with these, especially experienced ones who aren’t able to explicitly prepare. This makes the signal noisy and unreliable to us.
Ask candidates deep knowledge questions, like “what happens when you enter a URL into your browser?” These also have clear benefits, and we do require a baseline of existing knowledge. But deep knowledge comes primarily from experience, and we’re happy to take candidates who may not have as much relevant experience, but who are smart, quick learners, and hungry for growth.

“The interviews were well rounded and very well thought out. The people I met were professional, yet also friendly and approachable. Needless to say, I was impressed, and it left me with a very positive impression of the company.”

Many of the interviews above do provide meaningful signal, so we try to get an approximation of that signal through the other interviews below.

What we do

Today, we:

Ask candidates a basic data structures question in the context of a real-world problem. Specifically, we ask candidates to describe how they’d implement a simple board game and then extend it in various ways. The key thing we’re looking for is that the candidate is solidly comfortable with everyday data structures (like lists and maps), such that they can effectively apply them to solve the problem at hand. And because we focus on making the problem simple and realistic, this interview has proven to be reliable for us across levels and backgrounds.
Ask candidates a system design and architecture question, similar to common ones like “build a URL shortener” or “build Twitter” but with variants for mobile/frontend, backend, and full-stack candidates. With this interview, we look for a baseline of relevant domain expertise (like basic relational database design and a basic understanding of HTTP), as well as for candidates to again effectively apply that knowledge to a real-world problem. Experienced candidates can naturally go further here, so we also use this interview to gauge depth of knowledge.
Ask candidates to debug and extend an existing codebase as a live coding exercise (inspired by Triplebyte). We added this interview after realizing that navigating, understanding, and modifying a large existing codebase are essential skills in their own right — and fundamentally different than greenfield coding. It’s important to call out, though, that creating this interview was a lot of work. Designing a non-trivial, real-world codebase across multiple languages with good bugs and features that don’t require knowledge of specific tools and technologies wasn’t easy! We also tested this interview on our own engineers and iterated significantly. This work was clearly worth it, though: This has quickly become a very high-signal interview for us that candidates also appreciate.
Dive deep into candidates’ past experience. But we don’t do this aimlessly; we conduct two interviews specifically tailored to our four company values. One interview focuses on technical details, and only the hiring manager leads this interview. The other interview focuses on behavioral details, and non-engineers often lead these interviews. This gives us a well-rounded but focused picture on whether candidates share our company values, without falling prey to the classic Silicon Valley trap of ambiguous “culture fit.”
Invest in proper interview guides, explicit rubrics, and formal training for new interviewers — including shadowing, reverse shadowing, and debriefs after each interview to help calibrate. This is all in the service of helping us get consistent assessments across interviewers, which keeps our confidence high, combats unconscious bias, and helps us scale. This requires a serious investment as well, but is very much worth it.
Remember the human touch. Interviewing is a two-way street, and the details matter. From the very first phone screen to the very last interview, we leave time for candidates to ask us questions and ensure they all get answered. We discuss comp expectations and questions up front. We give a one-hour lunch break and reimburse the meal cost. We share behavioral interview questions ahead of time so candidates can think of their best examples. And we try to get back to every candidate quickly — no ghosting or leaving anyone hanging. As our recruiter Alyssa says, it means a lot to us when people take an interest in our team. We cherish that and try to treat everyone with kindness and respect.

I’m sure that what we do today isn’t perfect. We have room for improvement in all of these things, and I’m sure that we’ll iterate more.

Even so, I really appreciate where we are today. I have confidence in the signal we get, and I’m comfortable with the tradeoffs we make. Most importantly, I’m grateful that candidates appreciate their experience, too.

“I want to thank you and the entire Even team for making this the best recruiting, interview, and offer experience I have ever encountered. It is very clear that you care deeply about helping your candidates. I greatly enjoyed my time interviewing with the team.”

If you have feedback, send it to me — I’d love to hear it. And if you’d like to join, reach out! Hopefully your own interview experience will be just as positive. ❤️

Most of the credit for our interview process goes to my brilliant colleagues Evan Goldschmidt, Ryan Gomba, Olivia Bishop, and Jenny Molyneaux. Thank you!

Thanks also to the candidates who provided us with the feedback we’ve shown above. All quotes are real, edited only for clarity, and posted with permission.

Joining Even

2017-04-05T00:00:00+00:00

After five wonderful years, I left FiftyThree this past month to pursue something new. I’m grateful for the incredible experience.

For my next adventure, I’m excited to share that I’ll be joining the team at Even Responsible Finance!

Even is a tech startup aiming to fight income inequality. From the job post that drew me in:

77 million Americans work for an hourly wage. Their median income is $34,142… These Americans spend $100 billion every year just to make ends meet. They lose 10-30% of their income to things like payday loans, overdraft fees, and late bill fees. It is expensive to be poor.

Even wants to fix that, by building tech to help everyone — not just the wealthy — manage money better.

But importantly, Even is not a non-profit; it’s a legitimate business with great potential. The result is aligned incentives; awesome.

There’s much more I can say about Even, but I’ll save that ’til some more things are public. Some exciting things are in the works… =)

In the meantime, if you could use some help saving or managing your money, try the app and let me know what you think!

Even is headquartered in Oakland, CA, so with this new role, I’ll also be moving to the Bay Area! Let me know if you’re there.

And if Even’s mission resonates, the team is still hiring, across many disciplines. Maybe we can work together. =)

Thanks again to FiftyThree for a great five years, and here’s to hopefully the next five with Even!

Intro to CoffeeScript

2013-08-04T00:00:00+00:00

I’m a big fan of CoffeeScript. Daniel and I built all of Thingdom in it, and we at FiftyThree are building our next product entirely in it, as well.

Other JavaScript developers aren’t in such love. CoffeeScript has become a subject of great controversy, and it’s created a sharp divide in the community and ecosystem.

There’s nothing wrong with people disliking things, of course, or different people preferring different things. Variety is indeed the spice of life.

What I find sad, though, is that most people who dislike CoffeeScript don’t truly know it. They haven’t taken the time to really learn it, or even try it. Their reactions are usually knee-jerk, or based on fallacies.

I say this from experience. Daniel and I didn’t happily agree on CoffeeScript at the start; he pretty much forced it down my throat. But now, I’m grateful that he did — otherwise I may truly have never tried it.

The explanation for most people’s dislike of CoffeeScript is probably our natural resistance to new things and our comfort in what we know. And that’s precisely what languages like CoffeeScript are to programmers who aren’t used to them: new things that compete with what they know.

Paul Graham has written about a similar phenomenon in his famous essay, Beating the Averages. In it, he describes the “Blub Paradox” — when a programmer fails to recognize languages more powerful than the ones they already know:

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

Indeed, I, too, dismissed CoffeeScript when I first saw it. But now that I’ve actually learned it and used it, I see how wrong I was: CoffeeScript truly is more powerful than JavaScript.

This is the context I always set to people who are uninterested in learning new languages or tools: you can only know once you’ve learned and tried. And I keep reminding myself of this, too!

With that, I had the great opportunity to give a talk on exactly this — learning CoffeeScript — at the excellent QCon NY, and I’m happy to share the slides and transcribed notes here:

Like my Neo4j talk, be warned that this viewer may not work great in all browsers. It works nicely in Chrome on a laptop or desktop.

If you’re new to CoffeeScript, or even if you aren’t, I encourage you to give this a read. It covers a lot, so set aside some time. I’m optimistic that you’ll learn something new. =)

(If you’re already proficient in CoffeeScript, skip ahead to the section on classes for some fun metaprogramming tricks!)

So check it out, and let me know if you have any feedback. Enjoy!

Neo4j lessons learned

2013-01-24T00:00:00+00:00

For a long time now, I’ve been meaning to write a nice blog post about The Thingdom’s tech stack. Alas, that still hasn’t happened.

But, this past November, I had the privilege of giving a talk at QCon SF (an enterprise software development conference) on a part of that tech stack: a graph database we built on called Neo4j.

I really enjoyed preparing and giving that talk, but I never got around to polishing it up for nonverbal/online sharing.

Last week, though, I had the privilege of giving this talk again, this time to fellow NYC folks at the NY Graph Meetup. And that’s given me motivation enough to polish everything up for sharing.

So here it is — an online transcript of the talk with slides:

Be warned: I handwrote part of this viewer, and it might not work perfectly for you. For best results, view this in Chrome on your laptop or desktop.

If you’re interested in graph databases generally or Neo4j specifically, I encourage you to read this through. Hopefully you learn something new — and if you don’t, I hope you reach out and teach me something new!

The talk is roughly half a foundational intro to graph databases and Neo4j, and half a set of specific lessons we learned building The Thingdom (mostly around data modeling).

So check it out, and let me know if you have any feedback. Enjoy!

The making of

2012-09-22T00:00:00+00:00

I started this blog over a year ago. I promised to share my thoughts and ideas here, but that’s barely happened! Time to change that, and what better way to begin than to share the code behind this blog itself?

Context

Your first question may be, why is there any code at all? There are plenty of feature-rich blogging sites and services out there, and indeed, for most people, I’d unequivocally recommend using one of them. (I’d personally recommend Tumblr today.)

It’s a fair question, and I don’t have a great answer, but Marco Arment sums it up nicely:

I’m a developer. I make things…

This probably won’t sound sensible to non-developers. But it’s very important to me to have that level of control over my site.

With that out of the way, the next question was: How? What language, framework, tools?

There were three main factors I cared most about (and still care about) when making this decision (not necessarily in this order):

Development - it should be easy and fast to develop.
Deployment - it should be easy and safe to deploy.
Cost - it should, ideally, be free!

What you see today is the result of these factors. Let’s dive right in…

Act One

With hosted services out of the way, using something like Jekyll to develop with was a no-brainer. No database to manage and worry about, posts as just regular files, and support for Markdown; what wasn’t to love? (Tom Preston-Werner has a great post about the rationale behind Jekyll.)

Despite that, I didn’t like the idea of using Jekyll to power my entire site. Call me old-fashioned, but it just felt “wrong” to have to regenerate every single page when only the footer changed.

So using some sort of server-side scripting/templating language felt “right”, but at the same time (ease of development), I didn’t want to have to launch a server when developing locally.

I thus settled on using PHP with Apache: available by default on Mac OS X, always “running”, no build/compile step, and despite both their flaws, they’re both straightforward and simple to use for a case like this.

Part of the motivation for that was also that my domain, purchased from GoDaddy, came with free PHP hosting. (I’m not linking to GoDaddy for good reasons — I’ve happily moved to Hover.) I just had to use FTP for deploying, which wasn’t a big deal as I used Coda at the time.

Unfortunately, Jekyll didn’t play completely nicely with PHP, and the result meant a build step (a small one, but a build step nonetheless). Despite that, I went with it, and this Jekyll+PHP mashup worked for a while.

You can browse the code from this period if you’re interested.

Act Two

But pain showed up when I revisited this blog nearly a year later. In particular, FTP felt cumbersome and silly (I had moved from Coda to TextMate). Deployment was neither easy nor reliably safe.

It made sense now to move to git for deployment, just like I was already doing with “real” websites. Setting up my own git server felt like overkill to me, so it was time to move to an app platform in The Cloud™.

I was already familiar with Heroku, but Heroku doesn’t support “naked” domains (no www), and for a static site, it’s also expensive ($35/mo.), unless you’re willing to put up with long load times.

But I also knew that a potential alternative was GitHub Pages. After all, it’s specifically meant for hosting (only) static content, and it specifically supports (only) Jekyll for generating that content.

And unlike Heroku, GitHub Pages is free and fast, and it supports naked domains! (This isn’t documented clearly for project pages, but you just add an A record like you would for user/org pages.)

Unfortunately, GitHub Pages has two limitations: it only supports Jekyll — so no PHP or similar — and it even locks Jekyll down to disallow custom plugins — so no helper extras like LESS or SASS.

Fortunately, Jekyll does include support for a templating language called Liquid, built by Shopify. Liquid lacks the flexibility and expressiveness of “regular” languages, but it’s safe and secure for hosts like GitHub.

I was reluctant to switch to a completely new and less popular templating language, but the benefits of GitHub Pages outweighed these costs to me, so I decided to bite the bullet and port my site.

And indeed, the result is what you see today. You can browse this code too if you’re interested.

Details

Porting this site to Jekyll and Liquid for hosting on GitHub Pages wasn’t trivial — it was in fact filled with gotchas. And issues remain.

Liquid, for example, doesn’t seem to have a notion of (user-declared) array literals. That would have been useful in cases like the nav bar, e.g. to iterate over a list of links like ['About', 'Blog', ...].

GitHub Pages also uses an outdated version of Liquid, since updates to Jekyll are sitting unreleased, so newer Liquid features like index_of() and join() are also unavailable for use.

GitHub Pages also caches very aggressively — too aggressively for regularly updated sites like blogs. I’m not the first one to notice, and I’ve tried to come up with workarounds, but none have worked.

It’s not all bad, though. In fact, GitHub Pages has some great features that were delightful to discover.

Most useful is that it has simple support for clean URLs baked right in: a file at /foo.html can also be accessed at /foo (no trailing slash), as long as no folder /foo/ exists. This site takes advantage of that.

I’ve also been impressed by the thoroughness and thought that’s gone into GitHub Pages. MIME types, HTTP headers, even details like making sure HTML5 cache manifest files are never cached — good stuff.

Review

Overall, I’m quite happy with this new setup. Liquid is workable, Jekyll is great, and GitHub Pages is a pleasure to use overall.

If I had a wishlist for improvements I would love to see, it’d be something like this (in rough priority order):

Eased caching on GitHub Pages. Browsers could still cache pages; they’d just check first, and GitHub would respond with a 304 Not Modified.
Support for Jekyll plugins on GitHub Pages. This is understandably a security concern, but maybe the most popular plugins could be vetted and supported, just like Pygments is for syntax highlighting.
Support for another templating language in Jekyll. Liquid is great for non-technical uses, but it’s just so verbose and cumbersome for general-purpose templating. This could maybe be solved by a plugin.
If not, streamlined syntax in Liquid. Shorthand tags and operators would be a great start; variable assignment could also use improvement.

Still, the current situation is pretty fantastic: write posts in Markdown, deploy via git, and on a host that’s both fast and free. You can’t ask for much closer to “ideal” here.

Alternatives

But we all strive towards different “ideals”, and two alternatives are worth mentioning here.

The first is Octopress. This is a WordPress-level project that builds on top of Jekyll, and it’s simply impressive. In fact, this is strongly worth considering if you’re looking to start (or revamp) your own blog.

The second is Joe Hewitt’s Dropbox-based setup. The code behind the actual blogging platform is custom, and it requires server hosting, but you have to admire the nirvana of simply saving to publish.

I’m not aware of any other great alternatives, but let me know if you have any other recommendations worth checking out.

Onward

This site and blog have been an ongoing pet project, but after some effort, I’m quite happy with the current setup and workflow.

I’m also happy to finish this post and use it to kick off more regular sharing here! (Although just this post took me over a month of on-and-off writing, so don’t expect updates too frequently…)

With that, time to finally save, commit, and push. See you next time!

Joining FiftyThree

2012-08-14T00:00:00+00:00

Eighteen months ago, I left Microsoft to start The Thingdom. That journey officially ended this week, and a new one has begun.

After months of keeping it under wraps, I’m thrilled to finally share that my friends at FiftyThree have acquired The Thingdom, and I’ve joined them to transform our technology into something new.

FiftyThree is the company behind the award-winning iPad app Paper, and their mission is to bring creation tools into the post-PC era. If you hadn’t heard, they’re off to quite a start.

The opportunity is fantastic, but the team is simply world-class. I’m honored to work alongside some of not just the brightest but also the nicest people in our industry.

When we met, they joked that they wanted to turn “The Thingdom” into “The Ideadom” — a place to connect people around ideas and help them grow. That’s what we’re building now, and I couldn’t be more excited.

We’re just getting started, and if you’re interested in being a part of it, reach out — we’re hiring. Let’s invent the future together.

There’s much more I can say, but let me end it here for now and just say thanks to everyone who helped along the way. Your support was invaluable, and I couldn’t have done it without you.

One journey ends, and another begins. So it goes…

Introducing: The Thingdom

2011-09-12T00:00:00+00:00

I’m very excited to finally unveil what I’ve been working on for the past few months! I’ll start with the story.

When I decided to leave Microsoft, I realized that I’d need a new computer. Having experienced Apple hardware in the past, I knew that I wanted a Mac; the question was simply which one.

I spent time researching the various models and specs, but ultimately, I wanted more “human” data. I thus wrote up an (admittedly long) email to the subset of my friends who I knew had a Mac, asking them which ones they had and how they liked them.

Among those on the “To:” line of my email was my close friend and peer, Daniel Gasienica. Daniel is a big Apple fan (to say the least), so I valued his opinions in particular.

Surprisingly, answering my email wasn’t a chore for Daniel; he wanted to tell me what he had and what he thought, because he loved Apple and identified with their products. This was equally the case with my other friends, as well.

Stepping back, these were two sides of the same coin: I wanted to see what my friends had, and my friends wanted to share what they had. We had no other place to do these things, so we resorted to email.

People resorted to email for sharing photos, too, before Facebook and Flickr came along.

So this is what Daniel and I have been working on: building a place for people to connect around the things in their lives. We’re excited to finally share it publicly today; we call it The Thingdom.

So check it out, join (follow me once you do) and tell us where you think we should go with this! We’re just getting started.

Hello, web

2011-03-28T00:00:00+00:00

It’s been a few years since I’ve had a website to call my own. That’s certainly ironic, given that I call myself a web developer.

Most of those few years for me were spent at Microsoft Live Labs, home to some amazing people that built some equally amazing technology. At Live Labs, my thoughts and ideas were all public, whether through emails or frequent show-and-tells like those at the end of our out-of-the-box weeks. It was a very special community.

Now that Live Labs is no more, I’ve been longing to be a part of another such community, and what better one is there than the web at large? I’m especially inspired by GitHub; I was hooked the moment I made my first push, my first fork, my first pull request.

So this is my introduction. I’ll be sharing my thoughts and ideas here, and with your help, I hope we can make the web an even better place.