It’s been almost a year since I started a full-time software engineering job. If you knew me during my senior fall of college, the recruiting process CONSUMED me, most of it fueled by the obsession with finding the right job. Now, a year and a half after making the decision, I’ve noticed differences between what I thought mattered decision-time and what actually has actually mattered.
Mission
Picking a company whose mission aligned with my values was crucial to me, but mission ended up being one of the aspects of work that I think about the least. I’d still be fundamentally disturbed if I thought I was working for an evil entity, but for me, mission is almost better kept lofty and out of reach.
My current conclusion is if I believe in a company’s mission, and I see that the business model is not fundamentally at odds with it, I am fine working there. Coinbase’s mission to build an open financial system feels distant to my day-to-day work most times, and I’ve yet to suffer from moral qualms. Still, I check in with myself about once per quarter just to see if I still believe my work and the company trajectory somehow align with the mission, then I continue without an existential crisis.
The crucial personality trait to know here is whether you’re comfortable working for a mission in the distance, or need hard evidence that your work is actually impactful. Maybe sadly, turns out I’m quite ok with doing vague good or neutral to the world, and prefer a longer term vision over immediate effects. However, if you’re someone who needs to know their code changes are immediately beneficial, pick a mission and product accordingly.
Stack, or The Actual Work You’ll Be Doing
I only vaguely knew I wanted to be on the backend when I was picking a job, but this ended up being much more crucial to my average mood this year. Opposite to mission, the stack I work in and the technical problems I have to solve can’t be out of mind lol. I’d imagine one needs a very robust denial system to bypass monotony and misery, but amazing if you can do this (maybe with the help of a very noble mission). I’ve just learned that I can’t, and I got lucky that I like my stack and problems.
I don’t have a good rule of thumb for choosing stacks, so technical experience and noticing moods over time is best. I’m thankful that my intern manager remarked I always complained while making frontend changes, but actually found using the console exciting.
Compensation
This is the most quantifiable part of an offer, so it gets tempting to just pick the highest number. All personal preference, yet even for someone who fucking loves money, comp hasn’t come down to more = better.
Since end of 2018, I’ve finally learned how volatile startup stocks are. At the time, it felt like the only direction for valuations to go was up, but COVID happened and my highest stock grant is ~51% of what it was at offer time. For nonpublic companies, this won’t be real money until the IPO, so I’d value stocks separately from cold hard cash and actually look into company growth and profits and all that.
Salary-wise, I vaguely believe that skills are worth more than money, but also try your hardest to get the most money you can, and know when you’re lowballed! Negotiate the nonnegotiable offers, just so you’re not mad at yourself later.
Culture
This was also huge to me, but culture’s the hardest thing to read from a one day interview. It also might change in a year, or be wildly different across teams. To be honest, I thought Coinbase was too intense and cheery (in a fake way) when I interviewed, but surprise surprise, interview personas often aren’t people’s real personalities, and now the intensity is one of my favorite things about the company.
One macro trend that does matter is how the company handles failures. Blameless retrospectives will help any engineer be less nervous about changes, especially the mistake prone new grad. Without it, I imagine there will also be a lot of scapegoating, and that’s just avoidable toxicity.
Diversity matters tremendously to me, but it’s also hard to tell how programs and percentages affect experience. I joined my team of ~30 as the second woman, and frankly, I was prepared to be miserable until I proved myself. Very fortunately, my team is mostly the type of person that doesn’t make a lot of identity-based assumptions. This type of quality may be easy to tell for sharp people-readers, but otherwise there’s no good question for it.
Mentorship
I loooved asking people about mentorship and companies always had a canned answer something among the lines of “we have senior engineers who love mentoring!!” However, if every company already has a spiel for a question, that probably means the question is useless.
How a company thinks about mentorship matters infinitely less than what it does to promote mentorship. The answer to “what’s your mentorship culture” means nothing. “What’ss your onboarding process for new engineers” and “what kind of technical support are senior engineers expected to give” gives stronger signal. No process and no expectations doesn’t necessarily mean no mentorship; you will just have to fight harder to get help. It swings the burden of mentorship to culture and individual kindness instead of process, which is more unpredictable but maybe more organic. I’ve noticed shyer people tend to be more comfortable with clarity and process.
Judging quality of mentorship from a company is thus a mix of evaluating process and culture.
Ownership
The goal of mentorship, to me, is to make the junior engineer independent, and independence means owning shit. My biggest qualm about returning to Airbnb was feeling like I couldn’t “own a big enough piece of the pie” (literal words I used), and even in retrospect I have no idea what I thought ownership meant.
Since working, I’ve seen both desirable and undesirable ownership. In some companies, junior engineers are given a lot of ownership, but over dead-end projects that no one else wants. Of course, one starts from the bottom in the beginning of any career, but some software engineering tasks are purely operations, and owning them does not help in acquiring more advanced projects.
Owning desirable projects comes down to whether the team a) has desirable projects b) trusts or needs a relatively new person to own them. My team was constantly overbooked last quarter: while unsustainable long term, it meant I was able to lead both an asset launch and a major production migration as someone who’s never done either. This was a boon to my learning. How fast it happened was entirely based on the available opportunities, which was partially a stroke of luck, but also entirely dependent on the company having ambitious goals and my team being needed to fulfill them.