About me

I have a undergrad degree in mathematics from a top-tier American university and have been working in Silicon Valley for 10 years. I'm currently a principal engineer at a startup that was recently aquired by a second tier tech company (think HP / Cisco / IBM). I'm a named inventor on 8 patents, although half are "vanity patents" with little economic value. I have also made non-trivial contributions to several major open source projects.

Decision to leave

My startup was acquired and the management was forced out. I didn't like the company's trajectory, so I made the decision to start preparing for interviews.

I really, really, really wanted to work for Google. I wanted to work with other top caliber engineers. I am also paying for my wife to go to medical school and Google is among the highest paying tech companies.

I was afraid of interviewing to early and not doing well. If I failed my interview, I would have to stay at my current job for a year before I could try again at Google. I knew I would have to spend months studying.

Math and domain knowledge review

My domain requires a deep background in graduate level mathematics. I only have a BA in mathematics, but I took the standard first/second year graduate math classes as an undergraduate.

To review, I attended a virtual academic conference focussing on my domain. I watched each talk until I was no longer able to follow the math. I kept track of my missing knowledge and used my notes to prioritize textbooks for review.

Leetcode

I did about 200 leetcode problems. I started doing random easy problems to identify the fields that I needed to study. I quickly relized that I needed to relearn algorithms.

I created several favorites list to keep track of problem that I struggled with. I saved problems in groups based on their difficulty and my assesment of their importance.

I was eventually able to solve most leetcode hard problems in under 30 minutes. Some problems required verbose code to handle numerous edge cases. For such problems, I made it my goal to have the core algorithmic code written out in 30 minutes. If the solution required long sections of trivial code, I would stub out a subroutine and mark it TODO. I find that many interviewers (myself included) prefer to move on to another question and not waste time completing trivial TODOs.

General algorithms

As a pure math major, I never took an algorithms class. To prepare, I read CLRS cover-to-cover. If I had trouble understanding a topic, I watched the corresponding lectures on MIT open courseware.

I looked over all the exercises in CLRS. If I didn't see the solution, I looked up the answer online. I didn't write up any solutions, although I probably should have for better learning.

Since I had a strong math background, it only took me about three weeks to work through CLRS. Sometimes I even felt that I was slacking off and spending to much time on advanced topics that were unlikely to be covered in interivews.

For leetcoders lacking a strong pure math backgroud, I would suggest only reading the chapters covered by MIT's 6.06 Intro to Algorithms class. The remaining portions of CLRS are not needed for most leetcode hard problems, although some techniques may be required for optimal solutions.

Perhaps I'm biased as a math major, but I found that working throught the formal proofs was the most helpfull part of CLRS. A formal proof is only way to be sure that your algorithm works. Before working on leetcode hard problems, I would mentally sketch out a proof of the algorithm's correctness. The proof sketch helped me identify edge cases and ensured that I wouldn't need to backtrack once I started coding.

Green book

I did all the exerceses in Gayle Laakmann McDowell's book (Cracking the Coding Interview, aka "the green book").

Google's coding interview tool does not provide a mechanism to run code. Candiate are expected to debug by mentally stepping through the code. To best emulate the interview enviroment, I wrote up my solutions in a text editor. I only invoked the python interpreter after I had mentally verified the correctness of my solution.

Language choice: Python

I taught myself Python3 to use in coding interviews. I had done a bit of coding in Python, but I was far from an expert in the language. I chose Python since the "batteries included" approach allowed me to focus on the underlying algorithms

Code readability

Most answers posted on LeetCode's forums are quick-and-dirty hacks that pass all test cases, but do not explain the underlying algorithm. For FANG, the readability of the code is just as important as the correctness of the algorithm.

Some suggestions for writing readable python code.

• Named tuples. Named tuples make your code more readable. The meaning of heapEntry.price is obvious. The meaning of e[0] is not.
• Descriptive variable names. leftPointer and leftValue are better than lp and lv.
• Type hinting . Always use Python type hints, even if not using type checking.
• Split complex statements. Just because you can do it on one line doesn't mean you should.
• Short functions. Avoid excessive indents and split your code into small and readable functions. Use TODO comments to mark functions that you have declared, but not implemented.
• Comments. Describe and justify non-obvious aspects of your algorithm. Comments allow the interviewer to understand your intended algorithm even if your code has an implementation bug.
• Spelling counts. Incorrectly spelled variable names look sloppy.

Here is an example of a readable solution to a Leetcode problem: https://leetcode.com/problems/the-skyline-problem/discuss/1217077/python-heap-on-log-n-readable

Code style

I read Google's style guides and made sure I understood the basis for each requirement. I felt it was important to be able to justify my code style choices if an interviewer asked. I also wanted to be prepared to explain which style points were backed by logical justifications and which ones were just arbitrary preferences

A friend at Google suggested working on readability and style before diving into leetcode problems. It was good advice -- I made sure each leetcode solution did not just spit out the correct answers, but also showed the interviewer I could write code that other people could follow.

Cheat sheet

I prepared an interview "cheat sheet" as I encountered topics I was unfamiliar with. I intended to use the cheat sheet as a crutch if I needed to look something up during an interview.

My cheat sheet included:

• Python libraries and syntax that I found difficult. I included, for example, the function signatures from libraries like itertools, defaultdict, and heapq.
• Algorithms I had rarely used, but that might be needed for some problems. I had never encountered Khan's topographic sort or Kudane's algorithm, but I knew that they would be critical for certain problem classes.

If I came across a leetcode problem and I knew the cheat sheet could help, I looked at the cheat sheet first. I eventually memorized almost everything on the cheat sheet. I had the cheat sheet open during my interview, but I never looked at it.

Edit: Here is a link to my cheat sheet: https://docs.google.com/document/d/1b4XyPh2gDsMxYbUuW7woN7HXHh6kHQjwYRujn8RErHY/edit

Past experiences grid

Amazon's leadership principles are applicable to many companies. I prepared a spreadsheet explaining how I fulfilled each of them. I used the STAR format to give context to my interviewer.

Practice interviews

It was seven years since I had interviewed before, so I wanted to practice. I decided to interview with a few second tier Silicon Valley companies. I'm a bit of an Aspie and my social skills are not always the best. My first few interviews were terrible and I didn't get any offers.

I asked my wife to listen in on practice interviews and give me feedback. My wife isn't an engineer, but she was able to give me a third-party perspective on how I could improve my self-presentation.

Application

After six months of studying, I was able to consistently solve leetcode hard problems in under 30 minutes. It was time to apply.

I have lots of friends that work at Google, but none were in a position to give me a strong professional reference. I decided to just submit my application online and see what happened. A recruiter followed up the next day and asked to schedule a call.

Waiting game

The recruiter said that she would circulate my resume to several teams and get back to me. I expected this to be a short process, but I didn't hear back for three weeks.

The recruiter finally called back with good news: Several teams liked my resume. Furthermore, I could skip the initial coding phone screen and come directly to a virtual onsite.

Team lead screen

I was invited to meet with a hiring manager to see if I would be a good match for a given team. I was honest with the manager -- I had some of the skills he wanted, but I lacked experience in certain languages and was not as knowledgeable as other candidates with a PHD.

Virtual onsite

My virtual onsite was five rounds.

Round 1: Coding // Binary trees // Sorting

I first was asked to find the size of the largest univalue subgraph of a binary tree. The question was similar to Leetcode # 687, but I was looking for the size of the subgraph instead of the length of the path.

The best solution would have involved global variables. I wrote a somewhat convoluted solution that used multiple return values instead of a global variable. My solution was not the cleanest, but it was readable since I used namedtuples to pack / unpack the return values.

I only had 7 minutes left for the second question. The interviewer asked me to design an algorithm to sort a dataset that was too large to fit in the RAM of any one server. Most of the discussion focused on the O() tradeoffs if data transfer speed was orders of magnitude slower than an optimal O(n log n) sort on a given server.

Self rating: weak pass

Round 2: Coding // Multithreading

My second interviewer asked me to implement a re-entrant lock from just a lock. I kind of panicked when I saw the question -- I had never done any serious work with multi threading.

I eventually wrote up a workable solution, but the interviewer said it had a bug. I spent the remaining 20 minutes searching through my code. I tried to mentally execute each line and see if I ever encountered a race condition. When we reached the time limit, the interviewer spent a few extra minutes guiding me to my mistake.

Self rating: fail

Round 3: Domain // Past experience

My third interview focused on my domain expertise and my past experience. The interviewer was a (somewhat) well known Googler and I had read some of his publications. I was a bit intimidated -- I was about to be quizzed by one of the most well known names in my field.

Fortunately, his questions focused on the concepts he knew best and had described in his publications. Since I had read his publications, I sounded like an expert with my answers.

I debated if I should tell him that I recognized his name -- I didn't want it to look like I had only knew the answers because I read the papers. I decided to ask him if he was the same man who had presented at a recent technical conference. He said yes and seemed honored that I already knew who he was

Self rating: strong pass

Round 4: System design

I was worried about the system design interview since I had never built a web scale user facing system. Fortunately, the interviewer asked me to design a system that solved a problem in my domain, but not at web scale. I had built a simular system at my current job, so it was easy for me to explain the design tradeoffs

Self rating: strong pass

Round 5: Googliness // Leadership

The Googleiness interview was focused on my leadership skills.

I found this interview hard for two reasons. First, my past experiences were as an individual contributor and not as a leader. Second, I've been diagnosed with an autism spectrum disorder and my social skills are not always polished.

The interview ended up being repeatedly asked to explain how not to be a jerk. I sometimes felt like I was reciting tips from a website about improving social skills

Self rating: Weak pass

Good news

The recruiter called me two days after the interview and said that she had collected the initial feedback. Four of the five interviews were a strong pass. One interviewer had not yet submitted feedback. She asked about my salary expectations, if Google made me an offer, but she cautioned that hiring committee would still have to review my packet.

I was somewhat suprised that four of my interviews were a strong pass. Perhaps my self assessment was overly critical.

The offer

A few days later, the interviewer called me with an offer. I was invited to join Google as an L6 (staff engineer). The level suprised me. Most Googlers never make it past L5 and didn't think I was in the same league as the other L6 engineers I had met.

Compensation

I was initially offered:

• Base salary of $235k
• Target bonus of 20% (I'm told that most employees receive a bonus well above target)
• $500k stock
• No signing bonus

Negotiation

I was excited, but I put on my poker face and said that I would think about it after I looked at my other offers. (I was bluffing and didn't have any other offers.)

I decided to ask for a 40k signing bonus. I sent an email to the recruiter explaining that I felt I deserved a signing bonus since I would be forfeiting equity at my current job.

About a week later, the recruiter emailed me back and said that the compensation committee had approved the signing bonus.

Google was always my top choice, so I accepted and will start soon.

A concern

I did find it a bit off putting that Google's interviewer panel was all white men. All my other interview panels had at least one woman on them.

I shared my concern with my recruiter. I don't like being the only women on large team. She apologized and said about 30% of the engineers on the team identify as female, but that due to vacation schedules, she wasn't able to schedule any for my panel.