Taro Logo

Adapting to Big Tech

Profile picture
Entry-Level Software Engineer [L3] at Snap2 years ago

I started my career in a mid-level startup that was on the verge of IPO. I contributed a lot. Learnt a lot in terms of how to deliver big scale features relatively quickly, work within sharp deadlines, owning features and products. I was a high performer.

After 2 years of working in that company, I decided to switch to Big Tech for better compensation. While Snap is not exactly a Big Tech company, this is what I had in mind when switching.

I immediately started adding value in terms of delivering features and owning products. However, since I come from a mid-level startup, my soft skills are very weak. I am an excellent programmer, but I struggle writing Technical Design Docs. I deliver features quickly, but I don't know how to contribute to the spec sheets and writing launch emails, holding engineering sessions, efficiently using 1:1s. It feels like in my previous company, delivering features on time, writing quality code was enough to be a high performer, but seems like Big Tech requires a lot more. My manager's ex-Amazon, so he values tech docs a lot, and I feel like I am missing a huge opportunity here by not being good at them.

How do I adapt better to this work environment ?



  • 9
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    2 years ago

    I think you pretty much nailed it: You should get better at the non-coding parts of the job.

    The mentality shift you're describing is super common in folks transitioning from startups to massive tech companies, which includes myself as I switched from Course Hero to Meta.

    In terms of what to do, this is what I have in mind:

    1. Figure out the expectation in terms of code written
    2. Meet that bar established in #1 and spend all remaining time building up these other non-coding skills

    For #1, you can look at the number of commits landed by solid L3s and L4s on the team and try to match that. I had a really good relationship with my managers at Meta, so they were willing to give me concrete ranges like ~125 diffs landed being solid for an L4. I recommend trying to have that honest conversation with your manager. You can say something like, "I know that there's more to a SWE's performance than number of commits landed, but do you mind sharing a rough range with me that I can use as a guideline?"

    Another thing that comes with the shift from startup to Big Tech is that quality and precision becomes more important. Ask yourself how you can really level up the code quality you're putting out so it can handle Snap's scale. Some things to consider:

    1. What logging can I add to make sure my code truly works in prod?
    2. How many errors does my code through in prod? How can I get that lower in the future?
    3. How can I write this code in a way where it's easy to extend going forward? What features are we going to add on top of this code in the next 3-6 months?
    4. Are there any edge cases I'm missing as I put together the test plan for this commit?

    Now let's talk resources on getting better at those non-coding skills:

  • 6
    Profile picture
    Meta, Pinterest, Kosei
    a year ago

    The other thing I'd add to Alex's point is to focus a lot on understanding how people on the team spend their time. Can you look at their calendars, what docs they've authored, and what code they've written.

    This is the true test of what is valued within your team/org: what are the top performers spending their time on?