I had a great 2 years and 10 months of incredible learning and fun at Zynga, but in November 2017, I decided that it was a good time to look for a new opportunity.

I started my new job at Google in April 2018, and now that I’ve been at my new workplace for 6 months, I’d like to talk about my strategy and advice for switching jobs a few years out of college.

Table of Contents

• Timing
• High Level Planning
• Talking to Recruiters
• Studying for Interviews
• Negotiations
• Afterthoughts

Timing

When I told my mentor “The average tenure of a new grad software engineer in SF is apparently like 2 years,” he responded by saying, “Well, that’s for average people. We’re not average.”

Everyone has different things they look for in a job. For me, my priorities were (ranked in order):

• Gaining experience and expertise in a field I am interested in
• Working with smart and passionate people
• Being recognized
• Having a good work life balance
• Receiving a market rate salary

When I got out of college, I wanted to work on games. When I joined Zynga, in the first two years, I was able to interact with the codebase of a diverse array of games and tech stacks.

I learned from my esteemed game industry veteran mentors. I learned a lot about building APIs, client SDKs, ads libraries, and package management software. And though I wasn’t working on graphics optimization or coding game features, I could learn about these fields from experienced devs if I wanted to.

I was able to get a lot of recognition from Zynga, including two company awards and having ownership of important tech used across the company. I was even able to contribute to the Women At Zynga board and start a Women Engineers @ Zynga group. The people at Zynga were kind and made sure that my impact was recognized. It was extremely rewarding for me to have this level of impact two years out of college.

So why did I leave?

It’s important to note that I switched to a different team within the same org one year after joining Zynga (~ Fall 2016). I left the first team, the Ads SDK team, because there was not enough room for technical growth and too much firefighting. I enjoyed my second team much more, where I had more opportunities for growth both technically and in leadership.

It was around Fall 2017 when I was hitting a plateau in my interest and growth. By this time, I had spent close to a year as a tech lead of a team of five engineers for the same tech. I had gotten my promotion the previous summer and I felt like I was in a really good place. I had been in a “proving” mode for the first two years of my career, where I constantly tried to prove that I went above and beyond in my core work. After my promotion, I tried to identify my shortcomings and tackle it – going deep rather than fast, quality over quantity, and being able to give more technical direction to my team.

This period was really useful for me to better understand myself and what I wanted for the future. At this point, I realized that while I could keep growing technically in my current role, I could also switch into a new team or company and I would benefit more than staying.

Thanks to Zynga, my resume was in a really great place, so the opportunity cost was very high for me to keep doing what I was doing.

I looked at other teams in the company, but felt reluctant to switch teams and abandon my current team, because that team had the greatest need for me as an engineer.

High Level Planning

From college friends and people I’ve worked with at Zynga, I was able to build up my network and work with people who then went to work at other companies.

From this, I created a spreadsheet of opportunities where I listed about 15 companies with fields for:

• Contact person
• Status/Next steps
• Website
• Location
• Priority

At this stage, it was important for me to have someone who referred me to each company. The two companies I talked to without any referrals ended up fading out without going forward with interviews. Though this may not apply for all industries (the two were gaming companies), I highly recommend people get a referral rather than only working with their recruiter.

As for the priority, I wanted to have top choice companies and then second choice companies to apply to in phases so I didn’t run out of choices.

Then, I laid out rough milestones:

Month	Tasks
November	Study
December	Study
January	Apply to top choice companies, study
February	Interview at top choice companies, apply to second choice companies
March	Interview at second choice companies, take trip to Japan & Korea
April	Make decision

In reality, I received my two offers with the two top choice companies that I interviewed with in mid-February, so I made my decision only a week later.

I found it good to keep track of my interactions with the different companies in my spreadsheet as well, positive and negative. This helped me make decisions later on.

My regret is that I should have applied to more top choice companies in January. I only applied to 4 out of the 6 companies that I considered top choice, and 2 out of the 4 didn’t pan out (just recruiter calls, no interviews). As a result, I only had two companies to work with for negotiations. Note that the 2 companies that did not pan out started with recruiting emails, whereas the 2 that led to interviews and eventually offers were through employee referrals.

Just to recap, takeaways so far:

• Assess the opportunity cost of staying at your current job vs. finding a new job.
• Feel out the demand by starting to talk to a few recruiters or industry peers.
• Get referrals from employees of the companies you want to apply to.
• Be aggressive for the first wave of interviews: Have around 3-5 for negotiations.
• Apply to companies with similar salary ranges for maximum leverage.

Talking to Recruiters

For a larger company, I think it is good to do research and try to interview for as specific a role as possible. For example, my impression was that instead of applying for “Software Engineer” it was better to apply to something like “Software Engineer, Virtual Reality, YouTube.[1]” If you have friends or acquaintances at the company, try to get as much information as possible before talking to recruiters, since it seems likely that recruiters are associated with divisions in the company that may limit opportunities in other divisions.

I was lucky to have a recruiter from Google that was pretty transparent about the process I was going through as I set up my interviews, and I communicated strongly that I wanted to know if I had a “spot” somewhere I was interested in before interviewing. I think this works out both ways:I felt safer about my opportunities at the company, and the company was able to evaluate me in a specific context.

A smaller, medium-sized company will likely have an idea of what opening they are trying to fill. At my other top choice company, I made sure that I talked to the leadership of the team, my potential manager, and potential peers during my on-site interviews. I think it would be a red flag if a small or medium-sized company did not allow a candidate to meet their potential teammates.

Studying for Interviews

Overview

I am not good at coming up with tricks to solve puzzles. I’m totally fine when implementing complicated systems with lots of subcomponents, and I have pretty good understanding of languages and how to use them… but a lot of interview questions don’t assess this. People who are not “naturals” at pattern matching interview questions with a question they know how to solve will need to take some time to train for these.

This is a controversial topic! Why does it matter that a candidate be able to do this? Rarely does a someone need to implement topological sort and run through a tree from leaf nodes to the root on the spot without internet in a software engineering job.

It disadvantages people who aren’t naturals and don’t have time to become good at identifying patterns.

However, because I had the time and money, I decided to put in the effort to learn problem solving patterns and to get good at identifying them given an arbitrary question. After some time, it became more fun, like doing puzzle games. Because of this experience, I became less scared of puzzles and pointless coding challenges. I actually occasionally participate in my company’s codegolf competition thanks to this. (It’s quite a bit different, but still: coding for no end result other than competition.)

My approach was two pronged:

1. Build sustained awareness of problem solving interview-y questions by studying for three months before actual interviews using Interview Cake (more on this in this section).
2. Get good at interviewing through five mock interview sessions, provided by trusty fiance (as I had done for him when he was interviewing).

Why I used Interview Cake

In the past, I’ve only studied from the book Cracking the Coding Interview and by solving problems on hackerrank. The issue was that I didn’t get much better at solving problems that I was bad at (mostly dynamic programming and graph problems) because the study steps were:

1. Get the problem
2. Try to solve it
3. Get stuck
4. See the solution.

By seeing the solution, I would convince myself that I understood how to solve the problem, rather than learning the process for how to solve the problem.

This time, I signed up for a paid online interview training course called Interview Cake after a friend recommended it. Interview Cake walks through examples with hints and ways to think about it with good detail. I found this approach to be good at training the mind to identify patterns of common interview questions.

Interview Cake is a little pricey, so I knew I had to make good use of it. A book or a free service has no expiration date, which means more space for procrastination. The one year subscription system offered by Interview Cake meant that I was going practice practice practice that year, and if I didn’t get a job by then, I’d have to pay for another year of subscription. Also, the limited number of questions (~40) made sure that I got through all of them with a reasonable quota for each day. It supports multiple languages, so when I had to learn C++ for one of the companies I was interviewing at, I was able to pick up “interviewing in C++” through Interview Cake.

My Study Schedule

My study schedule looked something like this:

November

• Initially studied only on weekends, 2-3 questions per day.

December

• Started doing one question per night after work, and ~3 per weekend day.
• During holiday break, did about ~3 a day excluding busy days.

January

• Took a ¹⁄₁-¹⁄₉ off from work to devote my time to studying and relaxation.
• By the time I went back to work, I was finished with going through all of the questions from Interview Cake.
• I learned that I needed to do some C++ coding tests for the other company, so I started learning C++ on ¹⁄₉, going over the questions in C++. This continued until ¹⁄₂₀, all weekends and every couple of weekdays. I did supplemental C++ studies by reading online.
• Had mock interviews ¹⁄₇, ¹⁄₁₅, ¹⁄₂₀.
• Had one on-site for other medium-sized company.

February

• Had mock interviews on ²⁄₄ and ²⁄₁₀.
• Had the second on-site for other medium-sized company.
• The day before my only on-site for Google, spent ~6 hours on hackerrank solving easy/medium questions.

The mock interviews all focused on my weaknesses: graph problems and dynamic programming. I would say my success mainly attributed to the mock interviews, sustained practice, and luck.

Here is an example of a question asked during one of the mock interviews:

Search a Maze: Consider a black and white digitized image of a maze - white pixels represent open areas and blank spaces are walls. There are two special white pixels: one is designated the entrance and the other is the exit. The goal of the problem is to find a way of getting from the entrance to the exit. More details in the book: [2]

Negotiations

Things that I considered for deciding whether to switch jobs and for which job to take:

• My current total compensation (stock + salary + bonus)
• Offered total compensation (stock + salary + bonus + sign-on)
  • In case of a private company, also considering: vesting schedule, current value per share, approximate strike point
• Title/level offered
• The team’s answer to: “What’s the trait that you are most proud about your team?”
• My answer to: “Can I be passionate about this product?”
• Leadership opportunities
• Parental leave, vacation, and sick policy
• 401(k) match %
• Health & benefits

A few things I wish I had considered looking back:

• I didn’t push for a higher level from the beginning. My current role is the equivalent of a new grad’s level, though my salary is adjusted for my prior experience. It seems standard for 3 years of experience, and there are disadvantages with being hired as a higher level (being overleveled sucks). I recommend people bring it up early in the process.
• I could have shopped around for teams a little more after accepting the offer to see if there were opportunities other than the one that was proposed by my recruiter from the beginning. There is very little risk associated with this. While I love my current team, at first I did wonder “what-if?”.
• I should have interviewed with the other big tech company in the bay area (wink). The more offers you have, the better your negotiating position is – my current job was provided more leverage during negotiations than my other offer.
• If I were to optimize for compensation, I could have told my previous employer about my thoughts about leaving to leverage with a higher number. I got a stock refresh from Zynga right after I accepted the new job, and I did not tell them about my new job until 3 weeks before my last day. I doubt Zynga would have paid my time off had I told them I am leaving, but they may have offered me counteroffers to get me to stay, which I could then leverage.

Afterthoughts

My first three or four months at Google were pretty tough.

Somehow, when I got the job, I thought “I made it! I’m just like all my friends who also got jobs at Google.” Which was obviously not true.

I was just me, a well-educated (though I got B−s in most of my CS classes at Berkeley), well-regarded (at my previous job) engineer who worked hard to get decent at solving interview problems.Without the street creds, I felt like an imposter who slipped through the cracks in the interview process. I got good enough, but somehow not good enough.

However, through all of this, I realized that it’s okay to not be naturally good at these things. It’s good to be naturally bad, but be able to take time and effort to get good enough (and potentially beyond good enough) in the future.

My Google recruiter told me later on that I got something like 18 internal references. That made me very thankful and privileged for all of the personal connections I established throughout my life.

We are all born with different brains shaped by different experiences, and I now pride myself on having gone through this.

Since going through the experience outlined in this blog, I’ve helped two newly graduated friends look for jobs.They’ve followed the approach of outlining first choice companies, second choice companies, having a streamline of interviews, and getting mock interviews (from me).Of course, some people prefer a more ad-hoc approach, but they are glad that they went through their job hunt with me.

Some takeaways from helping my friends:

• Lack of confidence leads to fewer interviews, leading to fewer offers and thus less leverage. Know the demand, know that the interview process is far from perfect, and like dating, it is a numbers game.
• Schedule breaks in the interview calendar to recover. It is a draining process, so have people who can listen and empathize.
• It is okay to ask for more time before making a decision after getting your first offer. You will have to spend most of your weekdays at work, so it’s good to meet with your team before signing that offer.

I also recommend reading my Berkeley classmate Ronald Kwan’s Hunting for My First Full-Time Job: An Overly Honest Reflection post. His experience is for interviewing as a new grad, but he also recommends studying early and often for interviews.I found his honest reflection heartfelt and a good reminder for everyone to never give up.

To sum up my whole post:

• Think about the opportunity cost: Make the experience at the current job worth it. Whether it be building up your network, growing and learning new things, loving your job, or having a good work life balance, you should know your priorities and make the most of the time that you have.
• Be in the best position before scheduling interviews: Get referrals, schedule lots of interviews with similar-competitive companies, and get to know the company well before and during the interview process.
• Study a lot if needed: Sustained training of my interview-brain and realistic mock interviews worked well for me.
• Leverage multiple opportunities for the best opportunity: More competitive offers > Fewer competitive offers > Fewer offers. To make the best decision, try to get as much information, including about the products and team.
• You are You: Do the best you can do, and be kind to yourself.

Best of luck!

[1] Job title example from https://careers.google.com/

[2] Elements of Programming Interviews in Java by Adnan Aziz, Tsung-Hsien Lee, Amit Prakash