The price we pay

Stepan Parunashvili
Stepan ParunashviliDec 16th, 2019

I recently read Paul Graham’s Raising Kids. I loved the piece in its entirety, but a few sentences sparked something within me.

He wrote about what he missed about life when he was younger:

I remember perfectly well what life was like before.

Well enough to miss some things a lot,

…like the ability to take off for some other country at a moment’s notice.

I smiled with excitement when I read that. Yes! We have so much freedom.

But…there was a twist. In a few poetic sentences:

That was so great. Why did I never do that?

…most of the freedom I had before kids, I never used.

…I paid for it in loneliness, but I never used it.

Yes, yes. So much yes.

We have freedom. Yet we burden ourselves with faux responsibility or self-inflicted urgency.

Think about it: what feelings come to you, when you imagine doing something for no reason at all?

It can feel wrong on so many levels. Yet, where where are we hurrying too?

The time when we have real responsibility will come.

The time where we absolutely must focus on one thing, in one place, will come.

We’re already paying for the freedom we have. How can we embrace it?

Crazy Ideas

Stepan Parunashvili
Stepan ParunashviliDec 11th, 2019

Note: This piece is specifically directed to people who work at mid-large companies. The ideas will still apply to you if you work at smaller companies, but they’ll come as less of a surprise.

At any point in time at a company, you can find a bunch of ideas to make things better.

You can create features that make your customers happier. You can create tools to make your engineers more productive. Or…you can launch completely new products.

The questions to ask are “Who gets these ideas” and “How do they get those ideas?”

In larger companies, there’s an implicit understanding that ideas come top-down. It’s as though there’s a line for innovation: the best ideas come to the CEO, and maybe one day some of them trickle down to you.

Yet, is that how things work?

Thankfully, reality doesn’t work that way. If you look around you, you’ll see that some of the best ideas in the world come from some of the most unexpected places.

For example:

Memcached — did it come from a senior architect at google? Nope…young kid working on scaling their project (LiveJournal!).

Gmail — did it come from an ex-hotmail VP? Nope, 24 year old who tried creating an email client before, and decided to do that again at Google.

Airbnb — did it come from veterans in the hospitality industry? Nope…just a few friends trying to make rent.

Stripe — did it come from veteran payments execs? Nope…just two brothers frustrated with taking payments online.

This is happening all over the place externally. And, even though it may not seem like it, it’s happening all over the place at larger companies too.

Don’t believe me? Try this: look over a few of your favorite tools and products at work. Try to find the origin story. You may be delighted with what you find! (If you do this, I’d love to hear the origin stories that speak to you in the comments!)

We begin to see that ideas are not top-down. Well, how do ideas come then?

The more stories you see, the more you notice a pattern: Ideas come to people who face problems, talk to customers, and tinker. Paul Graham goes over this quite well in his essay on startup ideas, and they apply at larger companies just as well.

That’s really all you need to do. The beautiful thing about this? Notice what’s missing: title, pedigree, experience. None of that is required. Just face problems, talk to customers, and tinker.

At this point, you may be facing some resistance. You may think — it’s just not how it works at my company.

Yet…I encourage you to try and test your assumptions.

Most leaders want people like you. They know ideas can come in the most unexpected places. Now, there will be a spectrum of resistance. At most smaller tech companies you’ll find sympathy and support, while at more bureaucratic places you’ll face much more resistance.

However, If you try, you’ll contribute to the culture within your company that nurtures innovation and employee engagement. If you do this, you’ll give your company the ultimate competitive advantage and discover a bunch of like-minded people too.

Two action items, and a note

1. Action Item: #crazy-ideas

At Airbnb, we have a slack channel called #crazy-ideas. This is a space for people to get together and spitball any idea. So far we’ve found it great for encouraging innovation and engagement. I think Stripe has something similar (I was inspired to create this channel from a conversation with some of the engineers there). If you don’t have this, try starting one off at your company.

2. Action Item: origin stories.

In this essay I asked you to look into origin stories of some of your favorite products. What came up? If you’re up to share it, I’d love to hear!

3. Note: On facing resistance

As you test your assumptions, you’ll be surprised with how much you can do, but at some point you will invariably face resistance. There’s a whole trove of strategy here: aligning with teams, finding buy-in, managing up, building momentum, the list goes on. This will come for another essay. Meanwhile, if you start facing these problems, ping me and I’d happy to riff.

Thanks to Avand Amiri, Daniel Woelfel, Eric Ning, Jacky Wang, Julien Odent for reviewing this essay

Advice on starting out

Stepan Parunashvili
Stepan ParunashviliNov 20th, 2019

From time to time newly graduated hackers ask me: “Do you have any advice for beginning my career?”

I’ve found myself repeating 3 principles over and over again. On reflection, I realized these principles apply more broadly. I think they might answer the question “Do you have any advice on for beginning my life as an adult?”

I thought I’d share these ideas with you here. The style and the examples I wrote are career-oriented, but I think the core ideas will still help in your decision making. I hope you enjoy them : ).

Principle A: Follow your taste

What should you do? is one of the hardest questions to answer when you start out.

The default path is to follow what’s popular or prestigious. That can lead to a bunch of problems: What’s prestigious is already highly competitive. When you compete with smart people in a game that has established rules, just keeping up will take most of your time. That leaves little time to explore what interests you. When you don’t explore what interests you, you won’t understand things as deeply, and that leaves you with an undifferentiated skillset.

The solution here is to follow your taste. Popularity and prestige are lagging indicators. Your taste, especially as a young, curious person, is a signal for what will be popular in the future. Regardless though, when you follow you taste, you’ll find yourself much more interested in the problems you’re solving. When you’re interested in the problems you’re solving, you’ll discover deeper truths, build deeper expertise, a differentiated skillset, and have more fun along the way.

Now, you may be wondering: What if you don’t even know what you’re interested in?

Don’t worry. You just need to tune into and strengthen your taste. To do that, just do anything. Once you do anything, ask yourself, what part of that thing do you find interesting?

Start going deeper there, and all of a sudden, you’ll discover a wealth of interests.

Next up, you may be wondering: What if your interests keep changing?

Don’t worry. It’s totally fine. Just follow it. You’ll be surprised how things will serve you down the road. As long as you’re working hard and you’re learning, it’s a good use of time.

You may also wonder: What if your interests are what’s popular and prestigious today?

That’s great. Follow that, but instead of competing, start sensing what actually interests you in that field and go deeper.

The ideas may seem career oriented, so you may be wondering: What if I just want to travel and explore the world?

That’s great too! It’s your taste, telling you that you want to travel. Follow it and see where it leads you.

As you discover your interests, you may find that they’re not necessarily popular. Yet, when you go deeper and do your thing, something magical will happen…which leads us into the second principle:

Principle B: Find your community

As you explore and follow your taste, you’ll discover a subset of people who share your core interests and values.

Nurture those relationships. Some of these people will be your friends for life. Many of those people will become very successful in the future.

The people you know will show you what’s possible and work alongside you in deepening, exploring, and innovating on your shared interests.

You may be wondering: what if you live in the middle of nowhere, and there aren’t people who get you? Do your best to go to the center of wherever your community is. That may be SF for hackers or Los Angeles for entertainers or Paris for artists, the list goes on. You know where it is for you.

Now, this may sound impractical to you, but you’ll be surprised with what you can do. You can start off online in the meantime.

One common pitfall here is focusing only on successful people in your field. This misses the point. Sure, reach out to those successful people, but remember that the young, curious, interested people right next you, will become those successful people in the future. You have tons of time to spend together, so it’s great way to deepen your relationships. I’m not saying that you shouldn’t reach out to successful people (you definitely should), but to remove “success” as a criteria altogether for choosing who you spend your time with.

Now, you may be wondering, how do you deepen those relationships? That leads to us to the third principle:

Principle C: Take risks

As you form your community, new ideas and ways to collaborate will spring up. Take those opportunities: work together, support each-other and play. Over time, which you have a lot of right now, you will form a tight tribe of friends.

As a happy side effect, you’ll become exposed to new fields, new technologies, interesting problems, and interesting opportunities. Start taking them, and you’re well on your way to a career that’s made for you.

One common issue here is a lack of self belief. This may lead you into choosing what you think “you are capable of”, rather than what you’re interested in. One way to get around this is to just experiment: let yourself dream and work with your friends, even if the problems seem fantastically hard.

Final comments

There are a lot of examples I can give you if you’re interested in what I’m interesting in: From my favorite books to Paul Graham’s essays to Norvig’s Paradgims of AI programming, to Rich Hickey talks. But, instead I encourage you to think: what interests you right now?

If you’re up for it, I’d love to know your answer: what interests you right now? Feel free to leave your answer in the comments or to email me directly, I’d be curious to hear : )

Gratitude

There’s a slew of people who have influenced and mentored me. These ideas are just as much them as me.

On the idea of taste specifically, the big shoutout has to go to Paul Graham. A lot of my thinking about this was inspired by reading his essays over and over when I started out. I highly suggest reading them.

Thanks to Daniel Woelfel, Talha Baig, Martin Raison, Irakli Safareli, David Magaltadze, Joe Averbukh, Julien Odent, for reviewing this essay

Macros by Example

Stepan Parunashvili
Stepan ParunashviliOct 22nd, 2019

I was in a conversation recently about the power of macros, and the use of syntactic abstraction in building simpler systems.

We quickly realized though: it’s tough to convey in a conversation what’s so special about macros. What can you do with macros that you couldn’t do with functions?

In this essay, we’ll use 2 examples, alongside some imaginary javascript syntax and lisp [1] to explore that question!

Note: This tutorial assumes you have a light understanding of lisp syntax. Go through this tutorial to brush up if you haven’t gotten to explore lisp yet.

Note: I’ve been meaning to write this for weeks, but was worried that it would be confusing. I am going to apologize now if that’s how you end up feeling when you read this. There may be a better way to explain it, but I needed to get this out of the head. If you have any feedback on how I could make this simpler, please let me know 🙂

[1] The specific language is Clojure, but anything done here can be done with any lisp

Example 1: nullthrows

With this example, let’s gain an intuition for when macros run and why that can be powerful.

Context

In any language with nulls, there’s a nullthrows abstraction: If some value evaluates to null, throw it.

Here’s how we could implement that as a function in javascript:

function nullthrows(result) {
  if (result === null || result === undefined) {
    throw new Error("uh oh");
  } 
  return result;
}

So if we run it, and it evaluates to null, we’ll throw an exception

nullthrows(getUser(db, 'billy'))
// if it's null, throw Exception

This works great…but there’s a problem. What would our stacktrace look like?

index.html:700 Uncaught Error: uh oh
    at nullthrows (index.html:700)
    at someStuff (index.html:1325)
    ...

When some value is null, the stacktrace won’t have much helpful information. It will say which line threw, but we’d have to do some digging each time to find out where the code was.

One way we can fix that, is to pass in a message argument

nullthrows(getUser(db, 'billy'), 'expected billy');

function nullthrows(result, message) {
  if (result === null || result === undefined) {
    throw new Error(`uh oh: ${message}`);
    ...

This could work…buut

Challenge

What if I told you: I don’t want to have to pass in a message.

Instead, when the source code that nullthrows wraps is specific enough, I’d be just as happy if the error printed the offending piece of code.

For example, with nullthrows(getUser(db, ‘billy')), nullthrows is wrapping the source code getUser(db, ‘billy’))

If the error printed out “Uh oh, this returned null: getUser(db, ‘billy’)”, it would be specific enough, and I wouldn’t need a custom error message.

Problem

Well, by the time nullthrows is run, getUser(db, ‘billy’) will be long gone: all the function will see is the evaluation of getUser(db, ‘billy’). Since the evaluation will be null, there’s not much information we can gain.

Javascript Solution

To actually capture and work on source code, we need a new kind of abstraction.

This would be some kind of function, that does two things:

  1. It would take snippets of source code as input, and return new snippets of source code as output
  2. This abstraction would be called at the build step, and replace the source code snippets that it takes in, with those new source code snippets.

Let’s say Javascript had that. instead of function nullthrows, we would have macro nullthrows. It could look something like this:

macro nullthrows(sourceCodeSnippet) {
  return `
    const result = ${sourceCodeSnippet}; 
    if (result === null || result === undefined) {
      throw new Error("Uh oh, this returned null:" + ${stringify(sourceCodeSnippet)});
    } else {
      return result;
    }
  `;
}

Here, the input would be the actual source code.

Whenever it’s called, we would replace that piece of code, the source code snippet that this abstraction generates.

For example, during the build step nullthrows(getUser(db, ‘billy’)) would be replaced with:

const res = getUser(db, 'billy'); 
if (res === null || res === undefined) {
  throw new Error("Uh oh, this failed:" + "getUser(db, 'billy')");
} else {
  return res;
}

Now, you might see some potential problems here:

Snippets are just text! It’s really had to programmatically add/remove/edit text without causing a bunch of syntax errors. Imagine if you wanted to change the source code, based on what it was — is it a functional call or a value? — there would be no way to tell with just text.

With javascript, you can work on the abstract syntax tree itself with babel transforms, but that will make the implementation quite different from what we want our code to be doing.

We really want to use some better data-structures to represent our code. Turns out, this idea isn’t new: there’s a whole family of languages — the lisp family — that wanted code to be represented with data-structures so we could read/generate code snippets more easily.

It seems like a lot of work just to make a built-in code-snippet-generator for a language, but let’s see what our challenge looks like if we use lisp’s approach:

Lisp solution

Since all code in lisp, are just lists, our lisp macro takes in a list of code, and returns a new list of code

We would write nil-throws like this:

(nil-throws (get-user "billy"))

The function variant would look like this:

(defn nil-throws [res]
  (if (nil? res)
    (throw "uh oh")
    res))

Now, I’m going to show you how the macro variant would look like: (don’t worry about a few of the symbols you’ll see, they’re all simple and I’ll explain them in just a few words below)

(defmacro nil-throws [form]
  `(let [result# ~form] ;; assign the evaluation of form to result#
    (if (nil? result#)
      (throw
        (ex-info "uh oh, we got nil!" {:form '~form})) ;; save form for inspection
      result#)))

Here’s how we can think about it:

  1. Similar to how we wrote ` in javascript, the backtick here does the same thing: it says, hey, here’s the code I want to return, don’t evaluate it right away.

  2. # is a handy way to generate some symbol, that won’t interfere with any other symbol when this code gets replaced in a different scope.

  3. ~ is like our interpolation ${} in javascript, but for lists

  4. is a way to say: hey, I want to treat something as a list, and don’t want to evaluate it

This would make it so when we write: (nil-throws (get-user db “billy”))

It would be replaced (~approximately) with:

(let [result# (get-user db "billy")]
  (if (nil? result#)
    (throw (ex-info "uh oh, we got nil!" {:form '(get-user db "billy")})) 
    result#))

Wow…we just wrote code that wrote more code…that’s pretty cool

Lessons learned so far

Macros take code as input, and return code as output. They run during the build step

Example 2: pipe syntax

Now, let’s explore the kind of power this can give us.

Context

The pipe operator is quite common in a bunch of languages.

It takes code that you would normally write like this:

createBill(addToCart(cart, updatePrice(item, 100)))

And let’s you invert the flow visually:

item |> updatePrice($$, 100) |> addToCart(cart, $$) |> createBill

Challenge

What if our language didn’t have this, and we wanted to implement it? Maybe we’d want our syntax to look like this:

|> [
  item, 
  updatePrice($$, 100), // updatePrice(item, 100)
  addToCart(cart, $$), // addToCart(cart, updatePrice(item, 100))
  createBill, // createbill(addToCart(cart, updatePrice(item, 100)))
]

Problem

Now, we could do this by implementing a pipe function:

pipe(item, (item) => updatePrice(item, 100))

But we would need to introduce anonymous functions, and the code would be less concise.

The only way to do this to spec, would be to change the syntax itself.

Javascript Solution

Now, with our imaginary javascript syntax, we could write something like this:

macro |> (listOfForms) {
  return listOfForms.reduce(
    (lastForm, thisForm) => {
      if (isFunctionalCall(thisForm)) {
        return `
          let $$ = ${lastForm};
          ${thisForm};
        `;
      } else {
        return `${callFunction(thisForm, lastForm)}`;
      };
  });
}

Here, would start with a list of the forms, un-evaluated:

[item, updatePrice($$, 100), addToCart(cart, $$), createBill]

Reduce would start with the arguments lastForm = item, thisForm = updatePrice($$, 100)

Now, we would need a way to know: is this a form of a function call updatePrice($$, 100), or just a function: createBill

If it’s a function call, we can create new code, which defines $$ as the last form, and evaluate the function call within that scope.

Otherwise, we can create new code, which calls that function with the last form.

Lisp Solution

What we want would be something like this:

(|> item
    (update-price $$ 100)
    (add-to-cart cart $$)
    create-bill)

And our macro could look like this:

(defmacro |> [form & forms]
  (reduce
    (fn [last-v form]
      (if (seq? form) ;; am I being called: (update-price $$ 100)
        `(let [~(symbol "$$") ~last-v]
           ~form)
        `(~form ~last-v))) ;; or am I just a function: create-bill
    form
    forms))

Our lisp code would follow the same idea as our Javascript solution. Let’s see the code we didn’t have to write:

(create-bill 
  (let [$$ (let [$$ item]
             (update-price $$ 100))]
    (add-to-cart cart $$)))

…that’s pretty cool. We get the best of both worlds: efficient, well-erroring code that’s short to write and — most importantly — clear to read.

Lessons learned so far

Macros let you change the language itself. You can transform code and change the syntax.

Conclusion

Macros let you change your language to suit your problem. This is extremely powerful: You can build up your language so you can express your problem as clearly as possible. This makes your code more concise and simple, which in turn makes your system more malleable.

At the same time, macros…change the language itself. There are few moments where this level of abstraction is warranted, so if you use them when simpler abstractions would do, you risk adding unnecessary complexity.

Yet… when they are warranted, having them as an option can change the game.

Further Reading and Practice

If this got you interested, here’s some reading and practice you may enjoy:

  • Read Norvig’s Paradgims of AI Programming, and do the homework
  • Read Clojure for The Brave and True’s Macro Guide, and do the homework
  • Look into how Clojure uses macros to define the language itself (when, and, or, etc)
  • Write async await syntax for promises

Credits

Shoutout to Daniel Woelfel: I saw his nil-throws macro years back when we worked together, and it opened my eyes to the power of syntactic abstraction.

Thanks to Sean Grove, Daniel Woelfel, Martin Raison, Alex Reichert, Mark Shlick for a beautifully deep review of this essay.

Thanks to Paul McJones, perfunctory and tzs, for their feedback on the code examples.

Two stories I share with my nephews, to help them take risks and follow their curiosity

Stepan Parunashvili
Stepan ParunashviliOct 7th, 2019

Story 1: The Dice

I ask them:

Imagine there’s a game of dice. If you roll any number but 5, you give me one dollar. But, if you roll a 5, I’ll give you 600 dollars.

Would you play the game?

They invariably say yes.

(Some say, “depends on how much money I have”, which case I pat them on back, as they discovered expected utility. I then tell them though they have a hundred bucks at hand, and they say yes again : ))

Now I tell them:

Imagine someone walked by you and saw you play the game.

Most of the time, other people will see you lose. They’ll think you’re dumb.

Here they get heated, and say — heck, that person doesn’t know how big I’ll win! I agree, and then ask them:

Imagine now, it’a a 60-sided die. You still lose a dollar each time, but if you get a 5, you win 6 million.

They get excited by the millions, and say they’ll take it. Yet, I remind them, now if someone sees you, they’ll almost always think you’re dumb.

And from there, we get to the lesson:

It’s important to try for things, even if you have a small chance of winning. So…apply for that scholarship, try out for that team. Yes, maybe you’ll lose, and heck, you’re likely to lose, but that’s the whole point.


Story 2: The track captain and the climate change speaker

Note: I discovered this story as a kid myself from one of Cal Newport’s blog posts. I can’t find it, so will reproduce here. Highly suggest checking out his blog!

I start with:

Imagine two stories:

A. One person is the captain of their high school track and field team.

B. One person gave a speech on climate change at the United Nations.

Who is more impressive?

They invariably say B: climate change.

(If I tell this to Eastern European parents, they say A. track captain, because they think the UN person got in through insider connections. I tell them to ignore this though, and imagine it was earned :P)

I then ask: why?

After some minutes, I explain:

With track captain: you can _imagine_ how they did it.

If someone wakes up every day at 6am and works very very hard, they can become the track captain.

But with climate change it’s hard to imagine — how the heck did they get there?

From there comes the remarkable lesson about remarkable things: Remarkable things can’t be planned. If you can plan something into the future, surely it’s easy to imagine how it can be done looking backwards.

So…then, how do you do remarkable things?

The only path is to follow your curiosity. If you follow what you’re interested in, no matter how wacky it looks, you’ll look back after some time and say “huh”, how did that happen.

I then give them an example of how it could have happened for the climate change person: maybe they were into it, they started a blog, they got a group together, they wrote something that got shared, and boom, they made it to the U.N. That would have been impossible to plan.

This means follow your curiosity. Don’t get caught up by the urge to be #1 in some list at your school. Instead, talk with your like-minded friends, play, and see the world unfold around you

How to get those 9s: on improving service uptime

Stepan Parunashvili
Stepan ParunashviliSep 19th, 2019

What do you do when you inherit, or just as commonly, create, a service with low reliability?

Improving reliability can be daunting. You have low visibility into the system, and sometimes, if you inherited it, low expertise. The system is ever-changing, so if you just metric on success rate, you’ll consistently come across new errors, as soon as you fix old ones.

But…with the right strategy, improving reliability can be fun… maybe even thrilling! You’ll get to dive deep and solve some hairy problems. You’ll create solutions that not only improve your service…but improve all services in your company.

Now, to do this, I’ve come down to a strategy of three steps:

  1. Stop the bleeding: Represent the service as it is and hold the fort 2. Bring Observability: Identify the root causes weekly 3. Incrementally Improve: Retro and improve based on the most important root causes

1. Stop the bleeding: Represent the service as it is and hold the fort

This service is often already goal on uptime: maybe with that 99.99.

Most likely though, the service is failing that so consistently, that the goal no longer has any signal.

Our goal here: bring back the signal. To do this,

Action Item 1: Update the uptime goal to represent the current state of the system

Update the uptime, so that this metric to represent the current P99 uptime and latency values. If you do this, the goal should start to go green. This will help you become intentional about uptime slips moving forward.

This brings you back that signal. Now, just because it’s green, doesn’t mean . that you stop here and go on with our day. The next step is to improve it. To do that we need to

2. Bring Observability: Identify the root causes weekly

To have a meaningful approach to improving uptime, we’ll need visibility into your system.

Visibility in this case means the answer this question:

Question 1: What were the root causes of incidents last week?

The key here is root cause. You want to know: each week, what where the actual errors that brought down the system.

Action Item 2: Answer “what were the root cause incidents last week?”

You’ll need to invest in your tooling, to create a list of the big bugs that brought the system down.

Sometimes, especially in distributed systems, it can be very hard to get a sense of the root cause — a root cause could be a leaf node service error, and your infrastructure may not be aggregating by leaf nodes.

Nevertheless, it’s possible. You can look into observability tooling — the most promising one I know right now is www.honeycomb.io (no affiliation) — but more likely then not, you can use your existing tooling and an hour of manual work / scripting, to get a good sense.

Once you know that answer, you can

3. Improve Incrementally: Retro and improve based on the most important root causes

As you get this information, you can begin to run a “mini incident management” series:

Action Item 3: Create a “retro” series for fixing root causes

For the biggest error, take the steps needed to fix and remediate the root cause. This includes fixing the bug, as well as adding a test or an alert, or turning a hard dependency into a soft dependency.

If you do this consistently enough, you should begin to see our uptime improve. You can goal yourself on the top-line metric (uptime reduction), but also the number of root cause errors removed, remediations added (tests, process changes, etc), etc.

I read once in Nasism Taleb’s books: one plane crash, makes all planes safer. This is because the aviation agency investigates the plane crash, and makes sure that kind of error doesn’t happen again. This applies to your service too. When you do these retoes, you all of a sudden make your service better and better and better. It becomes…antifragile!

Summary of Action Items

  1. Update your uptime to represent the current state of the system
  2. Answer “what were the root cause incidents last week?”

  3. Create a “retro” series for fixing root causes

On leadership, self-esteem, and confidence

Stepan Parunashvili
Stepan ParunashviliAug 6th, 2019

Joe and I have a bit of a reputation. We’re known to have a high level of self-esteem — so much so that we’ve been asked “how do we do it?” quite a few times.

In this essay, I’ll try to answer how I think about it:

A. Your goal is to convince yourself that you are a confident leader with high self-esteem

Your inner critic knows you best, and they’re the hardest to convince. Yet they are the most important person that we need to convince: all our behaviors and beliefs stem from there.

Now, you could try to convince your critic by describing yourself as a confident leader with high self esteem: “Oh I’m confident, oh I’m a leader”

But your critic is too smart for that. If you try this the words will seem hollow. After all your inner critic knows what you really think.

To truly convince our inner critic we’ll have to get more concrete: what do these words actually mean?

To convince your critic, first

B. Identify the behaviors behind self-esteem, confidence, and leadership

Take a step back and ask yourself: what do these words mean to you?

Self-esteem: To me, self-esteem means you have strong core values, which you won’t change to appease other people. You are okay with who you are. You are capable of being vulnerable and risking rejection, because you value your self-opinion higher than those of the crowd.

Confidence: To me, confidence means, you go after ambitious goals because you believe you are capable of achieving them.

Leadership: To me, leadership comes from taking care of other people, empowering other people, thinking of others before yourself, doing the hard work, inspiring others.

Now you can start to describe yourself with these behaviors

Instead of I have high self esteem, you can say

  • I have strong core values

  • I stand up for what’s right.

Instead of I’m a leader, you can say:

  • I am a person who looks out and takes care of people.

  • I am a person who coaches and empowers people.

At this point your inner critic will start to listen…but we’ll need to do more before it catches on. To truly cement those beliefs:

C. Prove out behaviors with your actions

As life goes on, you’ll come across many opportunities to help others, to stand up for what’s right, to dig the ditches and do the hard work.

To illustrate how frequent these opportunities are, let’s think about something very simple. Say you want to meet your friends

  • Instead of waiting for people to invite you, take initiative and invite others
  • When you’re choosing where to eat, instead of asking yourself where you specifically want to eat, ask yourself, where your friends would enjoy eating the most

  • When you’re about to order, instead of thinking about what you want to eat first, think, would the group like some appetizers or drinks?

  • Now say you arrive, and you notice one of your friends drops a fork: take the initiative and pick it up, ask the waiter to help
  • Say you’ve been at this restaurant a few times, introduce yourself to the staff, and thank them for taking care
  • Say at the dinner there’s a pretty person you’re interested in, but they say something you disagree with. Stay strong and say what you think (I still struggle with this one :P)

These opportunities are everywhere. Notice them, pick them up, and all of a sudden, your description of yourself gains strength. With that you can begin to make the jump and tell yourself “I’m confident”. This time the words have depth.

The best part of all of this is that your internal critic will change roles: from critic to advocate. Initially, all they did was hold you back. But, as you train them to describe you with positive and worthwhile behaviors, the tone will shift: when something bad happens, they’ll start giving you reasons why everything will be okay, why you have the strength to deal with this, why you will behave with class.

This will reverberate throughout your life.

End Notes

1) One thing that helps: role models for these behaviors.

Personally, adventure novels (Scaramouche, Captain Blood) and anime (Naruto, One Piece) left an imprint on me. I often think about what some of my favorite characters would do in certain situations 😄.

2) One thing to watch out for: ego

It’s easy to take this thinking too far and begin to think you are special, an exception. You don’t have actually pay the price, you’re born this way. This is a recipe for disaster and it is very easy to fall into, especially when you receive praise from others.

What helps me:

  • Remember that we are all one, a part of a community. It’s weird to say this, but in case you don’t already believe it: All human life is worth the same, no matter what we do.
  • Tie your self belief to your actions: it’s easy to stop being a leader: all you have to do is let it get to your head and stop caring for other people.

3) This may generalize

Thinking about it, this generalizes to a whole bunch of other characteristics. How do you become a great communicator, or how do you become a great writer, an exceptional engineer? The steps seem the same. Something to think about!

Prior Art

  • James Clear talks a lot about the effect describing yourself can have in his book Atomic Habits. Highly recommend reading

  • My previous co-founder Sebastian Marshall would always tell me: judge yourself by your actions. This definitely played a part in my philosophy

And with that, we have a rough roadmap for leadership, self-confidence, and self-esteem 🙂

Thanks to Alex Reichert, Giff Huang, Joe Averbukh, Luba Yudasina for the review

My strategy for wealth and personal finance

Stepan Parunashvili
Stepan ParunashviliJul 31st, 2019

A few friends recently asked me for personal finance advice. I ended up creating a list of principles, and thought I would share it with you here.

Before you get started, a few notes;

  • a. These principles assume you want to create a significant amount of wealth (> 15MM), at a relatively young age (\< 40 ).

  • b. I’m not a multi-millionaire yet, so this is all a work in progress too :}

  • c. If you are just starting out your career, read this instead

Without further ado…let’s get into it!

Main Principles

A) Wealth creation is non-linear

Most people think you become rich linearly: by increasing a salary for example. But, wealth is highly non-linear: 1 year nothing, 2nd year a million

This means we need to think about creating wealth differently.

B) To create wealth, you need to take high-upside, high-leverage bets with people you respect

Most people think the way to create wealth is with personal finance: making investments, managing savings, etc.

But, unless you have a lot of money already, those are lower leverage. The best bet is to learn high-leverage skills, then use them on high-upside bets, with people you love. See Naval’s tweet for the best strategy about this.

Does that mean that we should just spend all our money though, hoping for the big pay day?

No, because:

C) To take high upside bets, you need money

Money in the bank increases the chance you have of seeing and taking these bets. For example, by having money in the bank:

  • You can make angel investments, or
  • invest in your friends, or
  • buy something that makes you much more productive, or
  • take time to work on a project that could turn into a company or
  • take your time negotiating your job offers or
  • outsource tasks to focus your creative energy

These all have high upsides, and can contribute to the step functions that will help you reach your goal.

This means that both the “entrepreneur, f** it until I make 30MM” and the “salary worker, just max the 401k” strategies are wrong.

Both of them are needed: because as you save, you start seeing more and more opportunities. But,

D) You need to be ready to spend to take those opportunities.

Most people, when they start saving, start feeling guilty about spending. This loses the leverage they have with their wealth. You saved, so you could take big opportunities and live your dream life.

So, how do we save?

Personal Finance Principles

E) Willpower is valuable and rare

Willpower is highly valuable, and we have very little of it. Most people spend it worrying about what to spend. But they’re in a losing game, because

F) People can’t control their spending and saving with willpower

If you feel guilty about what you spend, this will prevent you from taking those big opportunities. But if you spend too much, you won’t have the chance to take them.

It’s not worth spending willpower on figuring this out minute by minute.

Instead

G) Build systems, so you can save the way you want, and spend the way you want

Note: I learned this as a teenager, scouring the blog of the great Ramit Sethi of iwt.com. There’s gold there, check it out!

Create goals for yourself. Whatever you want in your life: don’t tell yourself no

Want to take a long sabbatical? Create a sabbatical fund. Want to take care of your mom and dad? Family fund. But how can you do those if you want to start a company? Startup fund

Set up the systems you need to move towards this. The simplest thing to create automatic transfers to those funds (more detail in Tools)

When you do this, you can save and spend with intent. If you want to ski, you want to start a startup, you want to live a rich life, it’s all possible.

Now, there’s a tricky part here:

H) As you make more money, lean into your system

As you make more money, it’s easy to ratchet up your lifestyle thoughtlessly. This can be dangerous, because it can take away your freedom to make big bets, which is the whole point of this.

To solve this, lean into your system. Increase your automatic transfers, and you’re good to go. Then, spend lavishly on what you value, with the confidence that you are on your way to your goals.

Once you do this, soon you’ll have a sizable amount saved up.

You’ll enter the next tricky part: losing all your money. You may think overspending is what will make you lose the money, but you’d be wrong:

I) People don’t lose all their money spending, they lose all their money by making bad investments

Note: I learned this lesson from one of Paul Graham’s essays. I’ve read them all many times, I highly recommend you do too

It’s not easy to spend a lot of money. But it’s easy to invest a lot of money, and have that disappear.

This is why it’s important for you to

J) Store the majority of your personal finance in highly-safe investments

This wealth is meant for you to take those big chances, so they should be available. Don’t go for the “10%” return options thing, which could end up wiping you out. Instead, buy index funds, buy bonds, buy property, gold — things that don’t disappear into thin air.

Now, you may ask: “what about the angel investing, crazy opps that require money?”

Create a fund for that. The majority should be in safe investments, so if in the rare case you really really need to make that investment, or take that startup opportunity, you can.

Tools

As one more mentor, Nassim Taleb says — nothing without skin in the game. What do I actually do, tactically?

Overview

I use Personal Capital, to keep an overview of my net worth, and how all the investments have been doing. I check this rarely — like once a month

Even more rarely (like once a year) I use Google Sheets, to manually go over investments. The goal is to make sure that I am invested in the things I value, and the allocations are right.

Banking

All payments initially land in Schwab Checking. Some amount goes to Fidelity to max the 401k.

Every 2 weeks, automatic transfers leave Schwab and get sent to Betterment. These go into conservative index fund combo accounts ~(70% stock, 30% bond). Some examples: Safety Net, Startup, Investment Opp, Parent Dreams, Real Estate, Extended Travel.

I also use Schwab Brokerage, and have a few specific investments (gold index fund, commodity index fund, AAPL, TSLA)

Allocation

Here’s my general allocation:

  • small amounts of: angel investing, to take high-upside bets
  • small amounts of: gold, commodities, to offset some worries i had about the market
  • small amounts of: AAPL, TSLA — bought them on dips, and believe in the companies long term
  • bit bigger amount of: Georgian Property. I want to stay connected to Georgia and fam there
  • majority in: 70/30% index fund accounts with names on em. These are highly-available assets, with the purpose of using them for startup / opp if ever needed

Summary

And with that, we reach the end. If you get only 3 things from this, I hope they’d be:

  1. Money gets made by taking high-upside bets
  2. To do that, you need to have some money, which means you need to be good at personal finance

  3. To be good at personal finance, you need to build a system, which lets you save, and just as importantly, spend, on taking big bets and living your rich life

Special thanks to Jacky Wang, Joe Averbukh, Lin Wang, Alex Reichert, Giff Huang, Luke Shackelford for reviewing this

10 Offers, 100 Days. The Journey

Stepan Parunashvili
Stepan ParunashviliJul 10th, 2019

In November of 2018 I kicked off a job search that lasted 100 days. I went through 11 onsites at companies like Google, Airbnb, Lyft, Uber, Amazon, Square, Stripe — you name it and I did an onsite there. Out of the 11 I landed 10 offers, and ultimately chose Airbnb.

In this essay I’ll walk you through that journey: everything from the spark, to the prep, the surprises, the work, the negotiation, and the ultimate decision.

My hope is first and foremost that you’ll find the story entertaining 😊. Second, I hope this gives you an insight into how the senior engineering job search looks like — I found little information that discussed what mattered the most at this stage, and I aim for this to open up new ways of thinking for you. Third, if you want to go deeper, I hope you check out https://jobsearch.dev, a free video course we made that lays out the tactics in detail. Finally, if you’re thinking about a job search, I’ll share why you should consider Airbnb and join — it’s a phenomenal time to make a difference here.

Without further ado…let’s get into the journey!

The Backstory

Note: What follows is the story behind why I chose to do a job search in the first place. If you’re looking for just the advice, skip to The Advice.

Day -30: The Spark

November was a special month. I had just finished a 2-year-long project at work called The Great Migration, and approached my 5th year at Wit.ai, 4th at Facebook. It was my birthday that month too, and it kicked off a lot changes: I moved houses, booked a trip and…even bought an electric bike.

I swear this isn’t a quarter-life crisis…

With all that change, I reflected on my time at Wit and Facebook and saw a decision point. My team was ready, our product was mature, our infra was stable(er), and The Great Migration was complete. For the first time in a long time I had a blank slate and could earnestly ask — what’s next?

Day -1: The Decision

At first, I saw only one option: I would start a new company.

My end goal has always been to build a company with life-long friends that takes a shot at a billion dollar problem. The time felt ripe. It was November too, so I could take a short stint skiing and reading, then back to SF to kick off the startup.

Yet, the more I spoke to close friends and mentors, the more I thought, the more my eyes opened up to different options. I could go deeper at FB, or I could join a new company, or I could do a sabbatical year, or…you get the gist.

So what to do? I decided then that before I make a choice, I should get the best possible options in front of me. How do we do that? by kicking off that job search!

The Advice

Note: What follows is the most condensed form of advice I could write on the job search, while keeping it fun and entertaining. I included personal stories to illustrate points, and where it made sense I refer out to sections in jobsearch.dev for more detail.

Day 0: Foundations

To kick off the search, there are a few mindset shifts that if done well, can make everything else simple. In fact, I’ll venture to say that some of these mindset shifts when generalized can change your perspective… on life itself!

Okay okay that’s a serious statement, but give this a read, try it yourself and let me know what you think after 😊.

Foundations I: Attitude

Most people dread the job search. They think it’s a kind of performance, and “they just want it to be over with”. This kind of attitude can shoot you in the foot. If you dread something, you’re less likely to invest the time needed to get great at it. That can produce negative experiences, which reinforces your opinion and causes a spiral of bad outcomes. Plus, if you “just want it be over with” you’re more likely to choose the first few offers and miss out on the opportunity that’s really right for you.

Let’s shift this. Learn to love the job search. You can look it as an infrequent, leveraged opportunity for you to grow. This is your chance to select exactly the right next move for your career. It’s one of the best times to negotiate your role and your compensation. Plus, it’s a great opportunity for you to expand and deepen your relationships: you’ll lean on your community throughout the search and meet many talented people at some amazing companies.

Well, that’s a lot of real good reasons to love the job search. Internalize this attitude, and every step that follows turns into a meaningful part of your life story.

Foundations II: Community

Most people treat the job search as a solo activity. They apply for jobs by themselves, they negotiate themselves, and they choose themselves. I think this is because people associate asking for help with dependance, and they’re afraid to make themselves vulnerable.

Now, this is fine, it’s an independent mindset. But we can go further. Let’s shift to an interdependent mindset. Think about it, teams achieve great things, not individuals.

Form a team around your search and involve them in every phase. Who are the mentors who can show you what you didn’t know you didn’t know? Who are the peers that can train you and give you advice? Who are friends who can refer you to the right companies? Engage them from the start.

For example, as you saw in The Decision, before starting the search I met up with friends and mentors to get their advice on what to do. I can honestly tell you that these conversations opened paths I could never have conceived before. People who champion you can give you ambitious advice that you may be afraid to see, and that changes the game. A special shoutout to my previous co-founder and life-long friend Sebastian Marshall, whose strategic advice changed was invaluable to me at this stage.

When I did start the search, I created a document that tracked the companies I was aiming for, alongside todos. This made it easy to share where I was at with my community, and easy for my community to discover ways they can help. Through this I received referrals at all 11 companies I aimed for.

When I began, two friends took the time to write up detailed advice from their last job search. Many, many friends took the time to train me. One of them was 12 timezones away and made time to skype for hours. They showed me where the bar was at, and gave me the feedback I needed to iterate.

Had 1 day in New York, 3 life-long friends took the time to give me personal training

Abraham Sorock, Alex Reichert, Andrew Wong, Daniel Woelfel, Giff Huang, Jacky Wang, Kam Leung, Mark Shlick, Robert Honsby, Sean Grove special shoutouts for the support and advice you gave me 😊. There’s many more — if you’re reading this and I haven’t included you, it’s mainly because I thought you preferred privacy — let me know and will update!

You’re starting to get a sense how interdependent this was. If I listed every person, I think it would surpass a hundred people. I truly believe if you embrace this mindset and look at problems as a team, you’ll see a huge change in all you go for, not just the search.

Foundations III: Narrative

We get to the final part of the mindset, how you look at your career. Most people, if you ask them “Why are you looking for a new job”, will give you either a generic answer — “I’m looking for a change”, “I want to be impactful”, or some negative story “I was bored”, “_I didn’t like X”. This hurts you in at least three ways. First, it’s what everybody says, and it demonstrates that you haven’t thought deeply about your career. Second, it makes it hard for people to help. If you tell your mentors “you’re looking to be impactful”, that doesn’t narrow much down, and They can’t just open up their rolodex to email every company they know. Third, it makes it impossible to be a _strong fit for any company. What can a recruiter note down if you say “you’re looking for a change”, which will let them think you’re a perfect fit for their company? If you’re looking for any company, then by definition you can’t be a strong fit for a specific company.

Instead, let’s shift your viewpoint and take charge of your career. Look at your career as an adventure. Sit down and reflect: What got you here? What did you love about your last job? What would the most amazing opportunity look like? As you go deeper, you’ll discover reasons that will get your thrilled, and show you how unique and awesome your path has already been. It will make the search a lot more fun, it will make it easier for people to help, and get recruiters very excited about you. Most importantly, it will change how you think about yourself and your career. Let me be clear, this isn’t some trick to change your viewpoint artificially. If you dig deep, you’ll discover real, true reasons, and that will reverberate throughout your life.

Day 1 → 5: Kick Off

Okay, now we’ve learned to love the job search, we see it as a team endeavor, and we have a strong conviction about our career. It’s time to kick off the search. To do that, let’s do two things:

Kick Off I: Communication

In every interview you do, people aim to extract signal and scope. Signal is what demonstrates that you can do your job — from coding to designing systems. Scope is what demonstrates the kinds of problems you can take on — do you lead a team, a team of teams, or the whole org?

The combination of signal and scope is what determines your level. Your level, and where you fall on the spectrum is the most leveraged decision for determining your compensation and the kinds expectations you have.

Many people get annoyed about this. It feels very bureaucratic. Why should some number define you? You may also know people who have “high levels” but produce less. Thinking this way can hinder you. Another way you can look at it is this: it’s how things are for now, and it’s the best way we know so far to align your skills with the company. Let’s lean in and work with it.

Your goal for the first 5 days is to form a conviction about your level. Go over expectations, and prove to yourself that you are the level you are. If you want to do go deeper on this, visit our course and see the “Communication” module — it gives you a leveling guide to calibrate. Once you’ve done this, update your resume and LinkedIn to communicate that level. When you speak with recruiters and interviewers, you should be able to freely communicate it as well. Finally, go to levels.fyi, and form a conviction about the kind of compensation ranges you’re looking for too.

Kick Off II: Schedule Screens

From consulting with your community and forming your narrative, you should have about 10 or so companies that you could see yourself being thrilled to work at. Now, engage your community and find a referral for each company. You can do this by searching through your LinkedIn, or sharing a document of your top choices with your community and asking them if they know people who can refer. Do the best you can to go through referrals, as having someone to champion you helps in many ways throughout the process. If you can’t find someone, it’s okay to send a direct application, but do that as a very last resort.

With all recruiters, ask to schedule a screen about 20–30 days in advance. They may be surprised, but you can tell them you want to prepare, and that will send positive signal too. With that, you’ll have a deadline, and a real good reason to start studying 😊.

Day 5 → 30: Preparation

Now comes the hard work. It’s time to ramp up for the technical interviews.

Preparation I: Key Mindset

The mindset at this stage I want to stress, is to give it all you’ve got. Sometimes, as a way of coping with rejection, people give themselves an out — “Oh I didn’t really study anyways”. My suggestion is to frame your success on how hard you prepare, not on the results. Aim to remove any reason to say, you didn’t try your absolute best.

Fun story on that — months before the search, I had trip planned with one of my closest friends to go to Israel and Jordan, and it fell right during preparation time…

Elements of Programming Interviews, 6am at a Bedouin camp

Well then, we need to travel and study at the same time 🙂. A special shoutout for Jacky Wang for being such an awesome travel partner, and being an encourager for the studies every day. Jacky’s the kind of guy who not only pushes the envelope to explore (just check out his photos), but he’ll indulge and converse with excitement about programming questions for hours on long car rides!

Preparation II: General Advice

There are three pieces of advice that apply generally to all interview types. First, the process to study: I recommend self-study first, then schedule practice interviews, then try the real thing, then calibrate and repeat the process if necessary. Second, approach every interview as if you are solving the problem for real. Most people seem to “pretend” when they solve the problem. They may not go deep enough, write code that won’t run, explain things for the sake of explaining, or create a system that won’t scale. Imagine a team at work set up a meeting and asked you to solve the problem, and act accordingly. Third, most people are blissfully unaware of what an excellent performance looks like. They assume the interviewer will read their minds and see how amazing they are. As you can guess, this won’t work. Study each interview type deeply, and get feedback on how you’re doing from your peers. Calibrate, make sure you are aware the bar, and you are well above it.

Now, for some more specific advice

Preparation III: Algorithm Interviews

Unless you’re a specialist, this is the interview type to master first. No matter how skilled and senior you are, algorithm interviews play a significant role. I suggest you pick one book — Joe and I prefer Elements of Programming Interviews — and work through it linearly every day (personal nit: skip the first chapter in this book on bitwise operators, this is the most annoying part of the book, and isn’t needed for most interviews). If you get stuck on a question, just look at the answer, but make sure to write it with your own code, line by line. By the end of it, you’ll be surprised with all that you learn, and I guarantee you, at least if you go through this book, you’ll rarely be asked a question that you can’t map to something you’ve learned.

One common pitfall here is, people go on leetcode and do a bunch of random questions. I suggest avoiding this — since the questions are random, you won’t see improvement quickly, and you may not learn what’s needed. Leetcode is great though for finding and doing specific questions.

A week or so after you’re into the book, schedule practice interviews. My favorites are https://interviewing.io and https://pramp.com. A special shoutout to the founder of interviewing.io, Aline Lerner. There was an obscure 19 year-old on hackernews who was having trouble coming to the U.S. She took the time to help, and even gave him free access to her lawyers. That 19 year-old was me, and I am still grateful 🙂.

The third or fourth week, schedule practice interviews with your friend group. This is where you’ll really get a sense of where you’re at. If the feedback is positive, you’re ready for the screens. If not, _move them. Y_ou’ll be surprised how many times you can do that. We go quite deep on this, and the kinds of questions you should be able to answer, in the “Algorithm Interview” module of jobsearch.dev.

Preparation IV: UI Interviews

For UI Engineers, I suggest three steps. First, get comfortable with online editors, you’ll be using them all the time, so you should be able to set up an environment quickly. Second, ramp back up on some UI concepts that you may not have worked on recently — things like drag and drop, selection apis, etc. If you’re looking for more specific inspiration, we’ve included some homework in the “UI Interview” module of the course. Third, explore the latest and greatest in JS — look up what interests you — from react hooks to all that’s new in GraphQL. If you’re looking for some courses, Wes Bos has some great content to ramp you up. The key to these interviews is to demonstrate your ability to build UIs and your love of UI engineering. If you follow these steps it’ll come through naturally.

Preparation V: System Design Interviews

For System Design, I also suggest three steps. First, master the structure — scope down, go broad, outline a complete solution, go deep on as many components as you can, then go the extra mile, to share how you would actually launch the system. The “System Design” module in the course does a great job of going deep on this. Next, as you go through the practice interviews, you’ll start to notice places where you can improve. Start noting those down and build a plan to learn. For example, if you don’t know how to scale, you can search “{Company Name} InfoQ” and find some awesome talks. If you’re unsure about concurrency, the book 7 concurrency models in 7 weeks can ramp you up. Don’t know much about databases? 7 databases in 7 weeks. Pick what interests you and start going deep. This is my favorite interview type, because as you go deeper, the skills and knowledge you learn transfers into making you a better architect.

Preparation VI: Experience Interviews

The purpose of the Experience Interview is to understand your scope — the kinds of problems you can solve — and whether you are a culture fit. This interview type largely takes care of itself if you’ve centered on your narrative (you know what you want and where you’re going), and your communication (you know what level you are). The first coneys your culture fit, and the second your scope. You can go deeper on this in the “Experience Interview” module in the course.

Preparation VII: How to Focus for these 20 days

Now you’ve got an outline of each kind of interview, and how to prepare. For the first 20 days, I suggest focusing heavily on Algorithms. If you’re a UI engineer, still do algos, but spend maybe 30–40% of the time building UI components too. You want to focus on this because the screens are mainly this type of interview. As you pass the screens, you’ll have to go deeper on systems before you head into the onsites.

Day 30 → 60: Execution

Okay, we’re now ready to execute. Over the next month, you should be finished with all your screens and on-sites.

Execution I: Key Pieces

Three key pieces of advice here:

Come in to every interview with a positive mindset, and treat everyone with class. These people could become your friends, and it’s fun to learn about how a company works. Come with that mindset, and the confidence will seep through.

Batch all the interviews. Make sure all the screens and onsites are scheduled around the same time. The preparation you can do part time, but this piece Joe and I highly suggest, you figure out how to do full-time. When offers land around the same time, you’ll have a lot more leverage.

Communicate your level and your narrative. Keep signal and scope top of mind, and communicate clearly during every phase — recruiter screens, technical screens, and and onsites. We go deeper on this in the “Interview Phases” module of the course.

Execution II: Dealing with the Unexpected

As you go through the onsites, two things can happen:

You’ll fail at some interview

As you may have noted, I did 11 onsites, and got 10 offers…that means I failed one of em 😄. Even with some of the most intense prep, sh*t happens. When it does, do not over-react, embarrass yourself by being mean, or change your plans and cancel all upcoming interviews. Instead, treat everyone with a smile and with class. Then, be kind to yourself, take out what lessons you can, and continue on with the plan. If you see failure on more than one or two interviews, consider re-scheduling and re-calibrating.

You’ll get something unexpected

Life can throw curve ball at anytime, and you’re unlikely to avoid it during the job search. Case in point:

Don’t try huge jumps on your skis, when you don’t know how, especially during your job search

On Christmas break, Joe and I went skiing. I did an unintended backflip, and landed in the ER. When something like this happens, again, avoid over-reacting. Treat surprises as an opportunity to be malleable, and make it part of your story. For example, the day I visited the ER, I had a conversation with one of the best recruiters I’ve ever met, Twitter’s Matt Robbins. I sent him that picture, and I wager that will be the most unique recruiter conversation either of us will have in our career.

Day 60 → 100: Choice

Around Day 60, offers should start to roll in, and it’s time to choose. The first surprise that people may have here, is the number of days. Most people take about a week or two to decide…Day 60–100 is 40 days! Does it really take that long to choose a company, even after you’ve received your offers?

Yes!

Let me be clear, this isn’t about negotiation. You’ve already done 90% of the legwork for that through your preparation and execution — if you communicated your level well, you’ve aced the interviews, and you landed your offers around the same time, you can safely assume every company will be competitive and get you the best offer. There are specific things you can do at this point — the main advice being to use clear with what you would sign right away with. We go deeper on this in the “Negotiation” section of the course. Patio11’s Salary Negotiation and Rands’ The Business are great reading too.

The reason this takes so long is because the purpose for this phase is to choose the company that’s the best fit for you. It’s your turn to interview back. Meet your team, meet your manager, really align on the kinds of work you would do, and let your future team show you how they could be a part of your narrative.

To give you context, Stripe, Airbnb, Square, and Google were my final choices. I ended up meeting 6 managers at google, and visited Stripe, Airbnb and Square offices at least 7 times each. By the end of these meetings, you’ll have formed friends, and have gotten a great sense of what it’s like to work at each company.

The final step before making the decision, is to get feedback from your community. I suggest you write out an essay that goes over your decision, and discuss with your peers and mentors — do they agree with your thinking, what do they see that you don’t, do they have any suggestions?

To get a sense of how this looks, here’s a compressed screenshot of the essay I sent my friends and mentors: “On Choosing”

Don’t squint, it’s not meant to be read

It’s a bit too personal to share outright, but I wanted to give you a sense of the kind of deliberation that went behind this: thousands of words, and insights from more than a dozen of my closest friends and mentors. These were amazing companies and the decision was close.

If you do this well, you’ll have clear, strong conclusions for exactly why you would choose a certain company. Compensation will be far away from the main reasons, and you’ll be thrilled to sign.

Day 100: Breathe

This will be a day where you breathe and realize how exciting, yet how tiring things were. Take a break and plan a celebration with your community.

With that, we’ve covered the advice 😊.

On Airbnb

What if I told you, that there’s a company which empowers millions of people around the globe to make a living?

What if this company did this through nurturing unique travel experiences, which furthered community and belonging?

What if this company was filled with people who were fundamentally kind and collaborative?

That’s Airbnb.

Plus, this is only the beginning. Think about travel today — do you think this is how it will be in 20 years? There’s a slew of less-then-ideal experiences, which translates to a slew of opportunities for you to empower more people, create delightful experiences, and have a lot of fun.

Now, it won’t be all roses: Unless we and luck have something to do with it, it isn’t clear that Airbnb will win in 20 years. To get there, there’s work to do in every axis — but that’s where the fun lies. If you’re ambitious, you have an entrepreneurial spirit, you like to hack and question dogma, Airbnb is the place where you belong.

Final Notes

An Ode to Joe Averbukh

I want to reveal something to you: any time I used the word “I” — you can replace it with “we”. Joe is my roommate and lifelong brother. Joe and I did this job search together, and we’ll both be joining Airbnb, in the same org to boot! We spoke every day, discussed every single exchange and every single idea, and supported each-other through all the highs and lows. Even writing this essay was Joe’s idea, so if you got something valuable from this, remember that at least half the credit goes to him!

Want to go deeper?

If you made it this far, and you’re pumped, get ready to go deep into the rabbit hole. Joe, Luba, and I, with the help of Aamir Patel and Jordan Yagiello, expounded on all the lessons learned here, and created a video course that will walk you through it all. From leveling guides, to example narratives, to deep explanations on system design, UI interviews, and more, you can get it there. Best of all, it’s 100% free. We were thinking of making it paid course initially, but after some long talks, we wanted to share this with our community 😊. Go to https://jobsearch.dev and see for yourself.

The best advice I received on leadership

Stepan Parunashvili
Stepan ParunashviliMay 6th, 2019

I once met a mentor of mine over some hummus. He’s one of the best engineering leaders I know — he truly takes care of his engineers and you can feel it. That day, he gave me the best advice I’ve ever received on leadership.

I was about to start in a leadership role at a new team. The expectations were large, and I was nervous about being able to deliver at that kind of scope, right off the bat.

So, I asked him what he would do.

He said, you only need to ask one question:

How can I help?

Come in, with a low ego, and ask — how can you help? How can you make the people around you more productive? What problems are they facing and how can you take some of them off their plate?

That’s the essence of leadership. The rest is table stakes