My reflection on the interview process in Silicon Valley coming from Asia
I’ve never studied Computer Science in school, never had any formal education in computer science nor attended any 3-month long Bootcamps. I landed in SF in June 2016 to attend WWDC, then started my month long interview prep/interview process and received multiple offers as I progressed. Eventually deciding to join Facebook as a Software Engineer at the end of July.
The purpose of this post is not to talk about what I’ve accomplished but to share my interview experience in Silicon Valley coming from Asia. A lot of people have been asking me about my interview process and how I prepared. Hopefully, this can provide some useful tips and advice if you are preparing for an interview. And most importantly, to remind people that you don’t need a master / Ph.D. from a prestigious university and a near perfect GPA, shiny resume to break into the tech bubble. If you prepare for interviews the right way with the right mindset and is willing to work hard, if someone like me could do it, so can you.
Who I am, where I came from:
After graduating from UCSB, I moved to Taiwan for my family. I picked up iOS development in Taiwan via an free online course on iTunes University, after 2 months, I made a few sample apps and interviewed for jobs in Taiwan. Gained some valuable real world experience & mentorship at KKBOX in Taipei for a year and a half before moving to 9GAG in Hong Kong for another iOS job for a few months, then deciding to come to SF.
How I prepared for the interviews:
Cracking the Coding Interview
A famous book that covers many basic CS concepts that are useful to know. If you have a lot of time to prepare, this is a good place to start. It’s broken down into many chapters that each discuss a fundamental CS concept. For someone like me who never went to school / learned anything about algorithms or data structures, going through each chapter helped me lay down a solid CS foundation to further understand more. If you had CS education, this might just feel like a review to you. Nevertheless, still useful.
What I did:
- I went through each chapter and tried to internalize each concept. The examples in the book is written in Java, but is fairly easy to understand even if you don’t know Java. I reimplemented the examples I saw using Swift (you can do the same in your favorite language). Then at the end of each chapter, there are a few problems with solutions in the back of the book that you can work through to make sure you understand the concepts.
Swift Algorithm Club
This is a bonus resource specific for iOS. If Swift is your favorite language, this is a fantastic resource. Its definitely easier and faster to get through than Cracking the Coding Interview because its condensed with better examples and in a language you are familiar with. Also its on github so you know its always up to date.
What I did:
- I went through every single concept in the repository and implemented everything on my own in playground.
Best place to practice interview problems. This website contains a wide repository of questions that might show up on interviews. You can sort them by frequency, by companies, by level of difficulties. After you submit your solution, the website compiles your solution and runs it through multiple test cases to validate your solution. So if you come up with a solution that is inefficient, it’ll let you know and not let you pass. You want to do as many problems as you possibly can for practice, eventually your goal is to be able to look at a programming problem, quickly identify possible solutions, analyze if your solution is the most efficient under time complexity and space complexity and be able to improve them.
What I did:
- I started off with the free version and filtered it with the easy problems first. In the beginning one problem can sometimes take 3–4 hours for me. But then I quickly realized, if your not coming close to a solution after 40 minutes, most likely you are going in the wrong direction of solving the problem. Maybe there’s a concept you didn’t catch, using the wrong data structures, or just need a gentle hint. There’s a discuss section where you can see other people’s solutions in different languages. Generally speaking, the one with the most up votes will be the one you want to look at first. Keep in mind that if the language you are using isn’t the more common one people use like python, c++ or java, it might be hard to find a solution in your language, sometimes the author will include sudo code and it’ll be a lot easier to understand. Totally okay to frequently check solutions when you are stuck, but the important part is to understand the concept and try to implement it without looking at the solutions again.
- After doing this for a while, I became faster and faster. I started seeing the patterns and catching the tricks. Recursion, using stacks or queues, when to use a hash map, the key word of “sorted” when dealing with an array. After a while of working on easy problems, I find myself doing them faster and faster, sometimes I catch the pattern and its a 5 minute solution right away. After a while of crushing the easy problems, I started doing more medium ones, and find myself crushing through them as well after some practice. Then I was able to do some hard ones, and at that point, you know you will be okay if and when you are given a algorithm problem in an interview. So in the beginning if you get stuck on every easy problem, don’t feel discouraged, its just part of the process, you will only get better as you power through them.
- I eventually paid for the subscription, it allowed me to search the questions by company tags, so you can literally click on a company, and it will show questions people asked at this company before submitted by users, and you’d be surprised at how accurate it is sometimes. It’s 25$/month in subscription but its nothing compare to salary you will be getting after this is all said and done. Easily one of the biggest return on investment I ever did in my life.
A website where candidates who interviewed at each company submit feedback, details of their interview experience and reveal what questions they were asked with solutions.
What I did:
- Before I interview for a company, I would typically search for the company, look at what position I’m interviewing for and what people say about the interview questions. It’s nice to know what to expect in terms of the formality of the interview. Sometimes you get some really useful hints or get lucky and get asked the same questions
- A few days before my interview, I will look up the company I am interviewing for on GlassDoor and carefully read through all the interview questions asked for my position and made sure I knew how to answer them perfectly.
After all these hard work preparing and studying. The most important part is the real experience. Just doing Leetcode and reading cracking the coding interview is helpful but is like learning how to swim by reading about it. You have to jump in the water to get a feel for whats it like under pressure, on a whiteboard without the help of autocomplete, references and a compiler.
Ideally you want to schedule as many interviews as possible for exposure and practice. And you also want to save the best for last, after you have enough practice and real experience and have time to work on your weakness you learned from your previous interview.
What you can generally expect is a minimal 3 round interview process.
- Non-technical phone screen with HR.
- Technical phone screen with an engineer.
- Skype or google hangout call and they will send a coderPad link with a question you need to solve. Usually you have 45 minutes to an hour. It could be a platform specific or general algorithm question. The goal here is to come to a solution and communicate your thought process effectively with the engineer.
3. Full day on-site
- The final round, usually consists of 4–5 interviews with different engineers from different teams. The format I’ve seen the most is starting off with a algorithm interview or 2, then a platform specific implementation or debug, then a design question on how you would structure the flow of the app…etc. Then could be a behavior interview, asking about your previous experience and projects with a more senior or director level engineer.
What I did:
- Before the night of the interview, I like to read through every single Leetcode problem that I have done(I did about 70 total), from easy to hard. Start with the most frequent ones and just read every problem again and make sure you understand your own solution, your time complexity and space complexity. Those questions come up more often than you think. This is just a refresher to keep your algorithms warm in your mind. Most of the time you get a problem you’ve never seen before but the solutions you done before can guide you to solving it. I then go through every single question that was brought up in Glassdoor again. Also prepare a bunch of question to ask at the end of the interview specific to the company about their tech stack/culture/expectations.
- A general pattern you can expect when you get an algorithm question. After you come to a solution, you’d then get asked the time-complexity and space complexity of your solution, then get asked how you would improve it. If you solved it using recursion, very likely next you will be asked to solve it iteratively and vice versa. So its good to practice solving the same problem both recursively and iteratively.
- A key thing to remember is almost no one looks at a problem and comes up with a solution right away, a often overlooked part of an interview is how you communicate with the interviewer. Even if you completely no clue on how to solve the problem, its okay! Don’t panic! Always think out loud. Even if it is stating the obvious. “Okay.. so we have an array here.. and it is sorted.. and what we are trying to do is…” “I’m just thinking about what are some of the data structures we can use for this problem” “interesting problem.. maybe we can use a hash table?” Let the interviewer know how you are approaching the problem. You might not come to a solution this way, but you give your interviewer the chance to guide you if you are headed in the right direction or warn you if you are going in the completely wrong direction and will save you ton of time. Believe it or not, the interviewer are usually inclined to want to help you and see you do well.
- The benefit about thinking out loud isn’t only that it enables the interviewer to help you. They are human too and get bored. If you just sit there and think in your head, not only its awkward, they’d get bored and thus not have a great impression of you. Communication makes the experience more fun for the interviewer. What I like to think is an interview should feel like a discussion between a mentor and a mentee rather than a interviewer and interviewee. General rules of human interaction also applies. be polite, smile, use your sense of humor…etc.
- When you have an idea on how to solve the problem, don’t rush into solving it right away. An useful thing for me was to first write out the pseudo code on the white board as I voice out lout my thought process. Once the pseudo code makes sense to you and your interviewer, the actual implementation becomes much easier. Or sometimes, the interviewer won’t even want you to implement it because he or she knows you can implement the details.
- My first real onsite interviews didn’t go as well as I’d liked, I was nervous, anxious and couldn’t think clearly sometimes. But after doing a few, I started getting into a groove, gotten use to the pressure of time and having an interviewer staring at me and felt very confident every time I walk into an interview room. Towards the last sprint of my interview process, when I lined up all the companies I wanted the most and went on-site everyday, it felt so natural and I actually started having fun with them. Every full day of on-site felt like a field trip, get to know some cool and smart people, solve some fun puzzles, feel their vibe working with them, have some amazing free lunch, then tour around the office imagining myself working here. I actually started enjoying these interviews and made sure I let them know how much fun I had while they hosted me in their office gratefully. I think at that point my confidence and calmness not only helped me perform better, but helped me leave a stronger impression as someone they’d like in their office / work with.
To put everything into summary; TLDR.
- I started off reading Cracking the Coding Interview, understood fundamental CS concepts, worked through some problems at the end of each chapter and checked solutions.
- Went through Swift Algorithm Club’s concepts and re-implemented almost everything on my own.
- Worked on easy problems on LeetCode, then started working on harder and harder problems as I got faster and better. Paid for LeetCode subscription to filter them via frequency and company. Eventually completed 70 problems
- Before interviewing at each specific company, study GlassDoor reviews closely in detail.
- Schedule as many on-sites as possible to practice get used to the real interview process. Review everything I’ve studied above the night before the interview. Get some good sleep and kill it the next day.
- Have fun, enjoy the process. Your confidence makes a difference.
Coming from Asia, straight into Silicon Valley’s tech culture. A lot of things were notably different in the interviewing process. I’ve never coded on a whiteboard nor really had any intensive multiple rounds of technical interview experience before. It took me some time to figure out how things worked, and how to go about them, thanks to help of many friends who shared with me tips and advice of their experience. A lot of people asked me about my interview experience and I thought it’d be a good idea to put it in an article to share the experience and hopefully help some people who are going through the same process. Good luck!