Hi Katie! Could you tell us about your background and how you moved from biology to computer science?
I was a biology major in undergrad and my first exposure to CS was during my junior year. By then, programming was the cool thing to do. Two of my best friends (shout out to Margaretand Katrina) were raving about it, so I decided to give it a try.
I loved it, but for many reasons decided I couldn’t pursue it at the time. I joined Teach For America and spent three years teaching middle and high school math in the Bay Area. After my third year, I had lived in the Bay Area long enough to realize I didn’t need a degree in CS to get a job as a software engineer. That summer, I applied to and was accepted at a coding bootcamp. In January 2014, I started working as a software engineer at a startup called Thumbtack.
How did you get your job at Google? Could you walk us through your regimen?
I practiced interviewing as much as possible. This is what I did during both my pre-Thumbtack and pre-Google job searches:
- Find a practice problem. There are a lot of resources these days, but if all else fails grab a copy of Crack the Coding Interview.
- Solve it on paper as if you were in an interview. If it’s tough, don’t worry about making your solution elegant or efficient. Time yourself and give yourself a time limit, something like 30 minutes.
- Type up your solution. Does it run? Is it correct? Bonus points for learning how to write unit tests and writing them now.
- Fix your solution. Use resources now if you need to, including looking at the answer. Analyze the runtime and memory usage in Big O.
- Make your solution cleaner and more efficient if you can.
- Put that problem in a pile to try again tomorrow or later in the week. Find a new problem. Repeat 100 times.
It’s time consuming, but I knew that I had to impress my interviewers if I was going to convince them that I deserved a job. Changing careers is hard, and embracing that helped me be successful.
What this process doesn’t get at is practicing the verbal parts of interviewing. Find opportunities to mock interview to practice that part.
What advice do you have for technical interviews? Any tips you can share?
During the interview:
- Bring a notebook and write down the question your interviewer asks. That way, you can add it to your arsenal of practice questions.
- Ask questions. As you summarize your understanding of the problem in your own words, you buy time for your brain to chew on the problem.
- Take two minutes to make a high-level plan, taking notes on the whiteboard or in your text editor. As you do so, explain your plan to your interviewer, verbalizing any assumptions you are making. Pick your data structures and be specific about what they will hold. Consider edge cases. State the runtime and memory usage in Big O.
- Verbalize the tradeoffs of your approach. Just like when you were practicing, it is okay if your initial solution is not the most ideal solution. You can demonstrate many important skills this way: translating ideas into code, readability, logical thinking, tradeoff analysis, asymptotic analysis, knowledge of data structures. If you have time later, you can build off of this to work towards a more efficient solution.
- Code, verbalizing your thought process as you go.
- Check your work. You should have a list from all of your practicing of common mistakes to watch out for: non-terminating loops, etc.
- If you have time, make improvements in efficiency, organization, or readability. If you don’t have time, verbally describe what improvements you would make.