Evaluating Work Opportunities

Recently, I spoke with a friend about job opportunities. I briefly shared with him my framework for deciding between companies, which I developed during my job search last summer. I want to expand on the questions and the thinking behind them — as far as I can tell, this isn’t common knowledge, and perhaps someone else will find it useful.

The framework centers around three dimensions, two which look at the upside (trajectory and potential), and one to cap the downside (sustained damage).

As a example, suppose it’s 2018, and you’re looking at a (entirely hypothetical) company called Basebook — a social network for baseball fans. After a few rocky years, they recently raised a bridge round, hired a “professional CEO”, and are starting to find some traction. MAUs have been growing 20% each month for the past six months.

This post assumes you’re evaluating work opportunities that provide meaningful ownership or profit interests (via stock options, RSUs, stock grants, etc), and that you could live adequately on any of the offered salaries. This post is intended to be a thought experiment — it is not financial advice, and I’m not a financial advisor.



This framework should be used in the final round of your decision-making, once you’ve made sure that all your opportunities address your table stakes. These might include:

  • Location
  • Team culture, and whether you’d enjoy working with the people there
  • A path for the kind of growth you’re looking for
  • Salary — enough to allow you to pay off debts and eliminate (or at least mitigate) existential anxiety


Trajectory looks at how well the company has been doing — it takes into account both the magnitude of the growth and how quickly it happens. Trajectory matters in both the growth of the business (customers/revenue/profit/cash flow), as well as growth of the product (shipping rate and value of what is shipping).

Interpreting these metrics will depend on the nature of the company. For example, strong growth in users may be a good thing if there is a clear path to monetizing users, or if there is a strong funding environment for user counts, but may be a neutral or negative signal if it comes with high CAC or a cautious funding environment. Similarly, a company might be generating little profit, but it’s collecting large amounts of cash up front (and presumably reinvesting its free cash flow). In the product dimension, a slow shipping cadence usually isn’t a good sign.

In Basebook’s case, the user growth trajectory appears promising. However, without other clear signals, it’s difficult to attribute clear value to that signal — MAUs on their own don’t necessarily lead to monetization. The rocky early years might be a negative sign for trajectory, if they were spent making bad decisions or pursuing misguided ideas.

If the trajectory on any dimension is flat or flattening, that’s a strong negative signal. Instead, look for accelerating progress. For smaller companies, it may be the case that many metrics are flat or humbly linear while one or two important metrics are accelerating. That may be a good thing — it’s a sign of focus.


How big is the company’s opportunity? This is different from asking how big the company’s market is — it should take into account the competitive nature of the market and the dynamics of customer acquisition. A market crowded with competitors, or one with difficult-to-reach customers, will likely cap the amount of the market any company could capture.

Alternatively, a company may be able to expand its market by rethinking the laws of economics and consumer behavior (example: Spotify) or the laws of physics (example: SpaceX). If the company can execute well enough to capture that growth, that can be massively valuable. A company may also be able to expand into other markets (usually adjacent, but not always) — Amazon is a classic example.

For Basebook, the market likely isn’t very large; the number of people who are baseball fans and want to use a dedicated social network is likely small. In addition, the fundraising market for social networks has cooled considerably, and user growth without profitability isn’t likely to be able to attract more funding.

Sustained Damage

I believe that companies sustain damage as they age. Most of it is self-inflicted; sometimes it’s external. Damage might come from specific decisions, faulty decision-making frameworks, or poorly handled events. Of these, faulty frameworks are the most insidious. It’s difficult to spot a systemic pattern of bad decision-making, except in hindsight (often when trajectory has already been impacted).

Signs of bad decision making include a lack of zeal or clarity, especially when asked about goals, direction, or the rationale behind goals or direction; a hesitation to make and commit to decisions; and problems that persist without apparent progress in resolving them. In fact, sustained damage, at first glance, usually looks more like systemic stagnation rather than outright negativity.

It’s possible Basebook sustained damage during the early years, especially if it wasn’t able to develop a strong culture and execution discipline (indicated by hiring a “professional CEO”). Furthermore, a bridge round usually leads to significant dilution, resulting in what you, as a potential common shareholder, would likely consider sustained damage as well.

There’s More to Coding than Just Writing Code

For most of my life I firmly believed that a Computer Science degree wasn’t necessary to work as a software engineer; there exists a massive amount of resources and practice opportunities to learn outside of the context and cost of a university degree. I maintained this perspective even after I ended up getting a CS degree, partly because of the lack of practical skills in a typical CS program.

I still don’t think a CS degree is a requirement, but more recently I’ve realized that it’s a very good proxy for a baseline of skills and ways of thinking. If nothing else, a CS degree indicates that someone has spent a lot of time understanding software patterns, becoming familiar with a range of patterns, and developing the basic abstractions necessary to understand more complex problems.

This post is based on observations from my personal life and interviewing junior and mid-level engineers for work. I taught myself to code in high school from a few books, got a CS degree along the way, and continue to refine my software thinking through higher-level books and videos. I work at Trustwork, a seed-stage startup in San Francisco with four engineers. For the near future, we’ve made the choice to prioritize shipping speed over harnesses and processes to train very junior engineers; at our size we don’t believe it’s possible to be great at both. This perspective underlies this post. This post is not intended to be specific to any technology, language, or library. This post doesn’t split semantic hairs — I use the terms code and software, developer and engineer, etc interchangeably. 

Understanding Software

At a first approximation, learning to code simply means learning to write code — the act of manual code generation. The much more valuable component is learning to think about software. In my experience, the latter is almost completely overlooked by existing resources.

The former approach conflates the skill of coding with the act of typing code. This approach generally consists of a rough project description, code listings, and descriptions of what the code literally does. The teaching approach is essentially “write this code, in the right place, and you’ll have a working project, which means you’ll understand what we did”. Success comes from carefully following instructions, and understanding rarely happens. The outcome for going through this form of training is someone who is very good at rote syntax pattern matching, someone who is good at putting network calls in the relevant framework-provided method and filling in boilerplate.

Admittedly, a lot of software is little more than boilerplate, but that’s a different topic.

Pattern-matching on syntax breaks down as soon as the syntax or framework looks unfamiliar. Instead, being able to pattern-match concepts and abstractions is much more valuable. For example, both snippets below represent a network request, even though they look very different.

Put differently, concepts and abstractions are the vernacular of software. As with human languages, an intuitive understanding of constructs and slang are a core part of being a native speaker.


Building Software

Syntax pattern-matching facilitates building up: writing software from a foundation to successively higher levels of abstraction. For each layer, the developer can take advantage of an intuitive understanding of the layer below because she just wrote it. She understands the abstraction, and can therefore make progress.

However, this doesn’t work if she’s asked to build down: plugging code into existing use cases or implementing an interface. During our interviews, we test this by showing candidates a code snippet and describing its intended behavior, and asking them to implement the API being used to make the code snippet work. Candidates who do well here are able to identify the functional concepts in the code snippet, as well as the potential seams in the stack of abstractions where they can insert their implementations. In other words, they’re comfortable being dropped in the middle of a stack of abstractions and building both up and down.

Thinking about Software

Beyond building software is building great software. There are many ways to define great code (elegant, clear, performant, well-documented, etc), but producing any kind of great software requires thinking about the code both granularly (perhaps in picking the best name for a function) and abstractly (perhaps when refactoring for readability or better performance).

Across the spectrum, this can only be done with a deep, intuitive understanding of both the application code at hand, and the breadth of existing software implementations and developer expectations.

A deep, intuitive understanding is characterized by simplicity — the hallmark of such an understanding is the ability to explain the subject in one short, clear sentence. It comes from wallowing in the complexity, understanding the subject one line or short chunk at a time, pattern-matching ideas and abstractions, until the whole subject becomes something you can hold in mind all at once. You can inspect the idea from different angles, zoom in to confirm details, and use it as a building block to understand a bigger subject. Some would call it grokking the subject.

Bonus: CS as a Common Language

Credit to David Ko for this line of thought

Practicality aside, the traditional CS topics form a common foundation and vocabulary when talking about software.

For data structures, a deep, intuitive understanding of how strings, arrays, hashes, and sets covers 99% of the code we write. A “deep, intuitive understanding” might be defined as being able to implement each of those data structures and some of their common functionality using the primitives of a language like C (where there are no existing standard library to hide behind).

For algorithms, I think being able to evaluate performance is more important to knowing how to implement any of the traditional ones. This means understanding what Big-O represents, and, crucially, choosing the relevant N. This also means knowing common latencies to within an order of magnitude, and being able to identify bottlenecks in an implementation.

👉 If this resonates with you, we’re hiring and would love to hear from you. Details here.

Photo credit: Fabian Grohs on Unsplash

Behavioral Observations from Taking Over SXSW

I just got back from taking over SXSW with Trustwork. We ran a scavenger hunt with multiple stations giving out free stuff in exchange for user signups. This post is the second of two posts on learnings and observations from that week. Part 1 is here.

My intent is to present some personal observations. It is not to disparage anyone or any usage pattern. I’m also not saying that Trustwork had a perfect signup flow — for example, we definitely could’ve had more performant code, and we had a contentious Confirm Password field.

Phone Usage

In my own life, I’ve been very conscious of how I interact with technology. I’ve cut off apps when I don’t like the interactions they’re inducing. As a result, it was a reality check for me to observe how most people interact with phones — a lot of behavior seemed instinctive, but laborious. Percentages are precise to within 10%, based on my own observations across a sampling of several hundred pedestrians in Austin:

  • When presented with an input field (for phone number, in this case), 80% of people instinctively started filling it out without prompting.
  • When presented with an entire form (name, email, password), 60% of people instinctively started filling it out without prompting. An additional 10–20% of people did so after a nod confirming that they should fill it out, before they knew where the information was going.
  • The vast majority of people (80+%) didn’t use autocomplete, instead filling out every field manually.
  • The vast majority of people (90+%) didn’t have any autosuggest-password feature enabled or didn’t use it if available. Based on the lack of thinking time when filling out the form, it appears that almost everyone reuses an existing password.
  • 30–40% of people mistype their password between the Password and Confirm Password fields. That stat could be interpreted either in favor of or against having a Confirm Password field.
  • The vast majority of people (80+%) didn’t use a password manager (this includes people who decline the browser’s dialog asking to save the password). Notably, one person manually entered his password into his 1Password app after signing up.
  • 30% of people had trouble getting around their phones. For example, we send an SMS verifying phone numbers. People had no trouble tapping on the notification to get to messages, but if asked to go back to the message after they left that app, some had difficulty getting back to it. Some people also had trouble finding their web browser.
  • 40–50% of the people who were experiencing very slow load times quit background apps in an attempt to make the site load faster. Doing so didn’t help.
  • 10% of people didn’t know their own phone number and had to look it up in the Phone app or from a friend’s phone

Human Behavior

Across hundreds of people, some behavior patterns become apparent. All of the above qualifiers apply here — this information is presented neutrally, without judgment; percentages are precise to within 10% and based on my own observations.

  • To “Free shirt?”, “Free cupcake?”, etc, responses were mostly binary — 90% of people either wanted the thing and stopped, or didn’t. Very few became convinced after some more talking.
  • Practically 100% of euphemistic Maybes (“I’ll come back later”, “On the way back”, “Let me grab my husband [who had gone ahead]”) were effectively Nos; they never came back.
  • 30% of people didn’t ask what Trustwork is before they finished signing up, or at all.
  • About half of the people who did ask what Trustwork is did so in the middle of the signup flow, usually after they already verified their phone number.
  • Most people who did ask about Trustwork were looking simply for some answer that seemed to make sense, rather than any genuine curiosity. As a result, it was possible to calibrate a couple of answers of varying complexity depending on the listener — my longest pitch took about 20 seconds; the shortest took three.
  • With groups of 2–3 (sometimes 4), it only takes one person to say Yes; the rest of the group will wait. Larger groups required more people to say Yes. If one person in a group says Yes, 80% of the time, the rest of the group will wait; occasionally they’ll convince that person to move along. About half of the time, the waiting group members end up saying Yes (usually because they were already on the fence; the fact that they were already spending time waiting was not an effective point).
  • For male-and-female couples, women led the interaction during the day, while men led the interaction at night.
  • Conversion rate, in rank order:
    • Free pizza was easiest.
    • Free cupcakes and cookies are easy, but it was difficult to manage “loss” — people who grabbed an item in passing, or who grabbed multiple items.
    • Free limo rides are mixed — some people are very skeptical, whereas other people jump at the opportunity.
    • Free shirts are somewhat easy. Availability of different sizes complicated things slightly, although most people were willing to accept sizes (S/M/L/XL) one step away from their stated size.
    • Free drawstring bags are moderately difficult.
    • Free photos were very difficult, although we got better results when it was positioned as the hardest-to-find item on the scavenger hunt.

Personal Lessons from Taking Over SXSW

I just got back from taking over SXSW with Trustwork. It was an exhausting eight-day marathon, complete with an air mattress in the office, questionable food, and hundreds of rejections a day. I wouldn’t want to do it again. Despite all that, it was a fantastic experience, and I’m really glad it happened.

For reference — Trustwork is essentially a jobs marketplace, backed by professional profiles for each user. It’s like the marketplace of Craigslist plus the reputation of LinkedIn plus the on-demand aspect of Uber. For the past week, our team of 20 stood on various street corners in downtown Austin giving out a variety of free stuff in exchange for user signups, one at a time. Most days were 10+ hours across a day shift and night shift; at our best we were sustaining over 200 signups an hour.

Our five giveaways, which played into a scavenger hunt with a mystery box at the end


At some point on the second day, rejections started feeling normal. When someone said no to a free bag, it stopped feeling like a personal failure; I’d simply move on to the next person walking over. This was due in part to a natural detachment (more on this below), but mainly my track record — I knew that every few minutes, someone would come along who would say Yes and sign up. All those rejections in between were simply part of the process to getting to that Yes.

To be entirely fair: we had a signup goal each day, but we didn’t have anything personal on the line. We weren’t being paid per signup, or per day. We didn’t need to get Yeses so we could afford food or shelter. But none of us wanted to let the team down, and unlike hired/outsourced teams, it was our company.

Beginning with day three, I kept a personal rejection quota in mind — my goal was to get at least 200 rejections (an arbitrarily-chose number). I didn’t really keep track during the day; it was intended more as a way to prime my mind than an actual goal.

At some point I realized that the people passing by were only rejecting what I had to offer. It wasn’t personal; they were saying no to “free shirt?”, not me. This led to a natural detachment made it easy to de-personalize each rejection.

I spent time working each giveaway station, and came to see that the rejection rate varied dramatically based on the item and positioning. Free pizza and cupcakes were easiest. Free photos (akin to a mobile photo booth) were the hardest; we fell flat, and axed the idea halfway through the first day. (Photo booth was later resurrected as the hardest-to-find item on the scavenger hunt, to greater success.)

Finally, sometimes the rejections were downright funny. A sampling:

  • To “Free photo?”: “I can take my own **** photo”
  • To “Free cupcake?”: “I ain’t eatin’ that shit!”
  • To “Do you have a phone [for free pizza]?”: “No man, I lost it last night tripping hard on acid”
Free cupcakes drew crowds

Personal Interactions

Sometimes, a Yes turns into a great interaction, in a variety of ways:

  • People have interesting stuff on their phones. Typing in “tr”, some brought up Trump results. Others surfaced a search for “trust fund baby”. Adult content, unsurprisingly, made an appearance as well.
  • Sometimes we’d ask people to add a profile photo. Many people took selfies on the spot, and posed in a variety of ways. Occasionally, they’d want to take a selfie with us. After one particular photo I took with a guy, he said “dang, you look like a damn model!”
  • The first step in our signup asks for a phone number. One guy saw that we were successfully exchanging pizza for numbers, asked us for an empty box, and proceeded to go around trying (unsuccessfully) to get phone numbers until I asked him to do that somewhere else.
  • A few days in, a group of guys came by and said “You guys are legends!” They’d gotten the free cupcakes, limo ride, and shirt, and told us that Trustwork made them think of “hustling entrepreneurs”.
  • Free pizza and free limo rides offered to a late-night crowd led to some interesting interactions. Details are left to the imagination.
  • I found myself matching the volume and mannerisms of the people I talked to. I slipped into more accents than I thought possible, and said “hey man” (which I normally never use) enough times to embarrass a hippie.
We signed up a wide variety of people (as intended)


The combination of late-night shifts and activation energy (the willpower needed to prime my mind at the start of each shift) made for an exhausting week. But on balance, the entire experience was deeply satisfying, and I’m very happy to have done it.

Something really interesting happens when you work closely with a group of people and share in the struggle of a difficult task. At some point, quite suddenly, people let down their guard, and you get to know what they’re like at a more human level. This leads to better stories, funnier jokes, and shifts the balance of selective memory (more on this below).

Across hundreds of interactions with strangers, I was fortunate to make a bunch of observations on human behavior and how people used their phones. More on this in Part 2.

Most of those interactions were a net positive — ranging from the satisfaction of closing a Yes, the incredulity when people realized we were giving away free pizza (I was asked “why are you doing this?” several times), and the excitement of our scavenger hunt winners. This further shifts the balance of selective memory and contributes to that feeling of deep satisfaction.

Since each interaction was relatively quick and occurred frequently, it formed a rapid feedback loop allowing me to improve my pitch and selling ability. I settled on three versions of my pitch, tailored to different listeners and varying in complexity, and committed them to muscle memory so I could focus on other interaction details (identifying who was interested, who had the slowest phone in a group, and loading the signup page on my phone to make it easy to set everyone up). Mastering the pitch allowed me to get into a state of flow when interacting with a group of people, and it was exhilarating to perfectly narrate and time the pitch and signup process across a group of three or four people.

Coming into this week, I would not have thought that street-corner sales was something that I could do. I’m happy to have proven myself wrong — to know that it’s something I’m capable of doing, and that I even enjoy it.

Working hard or hardly working?

Selective Memory

Selective memory is an extension of the idea that people remember how they felt, but not the details, as well as the peak-end rule. If you know yourself well, you’ll know the types of details that you’ll remember and forget after an experience is over. For example, I know I’ll remember the conversations where everyone can’t stop laughing, the satisfaction of delivering joy to strangers, and discovering cool restaurants in a new city — but I’ll forget the hassle of setting up an air mattress each night.

If you’re deciding whether to do something, selective memory can be used as a framework (possibly in combination with fear-setting) to discount certain aspects of the experience to determine if it will be a net positive.


I’ve moved 8 times in the last 6 years. Every time, I somehow manage to package my life into a few boxes, bags, and loose bundles of stuff. Every time, it seems simple at first — looking around, I have a cup on the counter, some spices, tea, and chocolate in the cabinet, a few scant pieces of furniture, and seemingly not much else. A few shelves’ worth of books, some toiletries, and cookware. Oh, and a full closet of clothes (plus overflow on a shelf, on the floor, or left in the dryer from the last time I did laundry) … the sheer amount of stuff I have only becomes apparent as I take everything out of its hiding place in drawers, shelves, and nooks, laying it bare on my countertop and floor.

I’m very conscious of this because I don’t like having stuff. I certainly like the idea of having less stuff in my life, and often wish I had fewer, painstakingly-researched items rather than the smorgasbord of mismatches and seemed-like-a-good-deal-at-the-time things I’ve somehow accumulated. Carrying around a bunch of stuff that doesn’t inspire joy feels oppressive, almost as if the items have become an unpleasant part of my identity. It probably doesn’t help that every time I pick up an item, my mind starts thinking about how I could use the thing in the future, or what-ifs where I would need the thing, overlooking the fact that I haven’t actually used the thing in years.

During my most recent move, I got rid anything that I hadn’t used in the past year, although there were certainly many times when I tried very hard to talk myself out of doing so. Now that it’s done, I’m glad to have been able to get rid of a small closet’s worth of stuff. Next, as I unpack, I’m planning to go through everything meticulously, and hope to repeat that accomplishment.