What's up.
I've been studying CS fundamentals to grow my skills and interview at bigger tech companies. For the next month, I plan to write about what I'm doing to prepare. As interviews are approaching, this will definitely help consolidate all the knowledge.
This post mostly follows the Google Interview Front End Prep Guide, with my own twist to it. I've highlighted the things that are important to me (ie. review further, etc). Possibly, some of these will be their own blog posts.
The Google prep guide starts with some interview tips that fall within 4 categories: explain, clarify, improve, practice. Being able to explain your thought process and decisions signals that you're aware and knowledgeable of things that they look for. In practice, this section seems to provide input on how they score candidates. Has him/her explicitly stated and checked their assumptions? Can you properly deal with open-ended questions? So, can the candidate design better examples from bad ones on their own? Can the candidate devise a brute-force solution, then optimize it while thinking
out loud (explain what's being done and why). And
finally, did the candidate re-read and interpret the code manually to check for errors? Check. Check. Check.
Moving on. So what are the Google's official requirements for front end?
It's a two parts format: Coding & algorithm interviews and a technical front-end interview. An interesting fact: Their guide specifically uses plural for part 1 (coding & algorithm) and singular (so one interview) for part 2 (the front-end). I need to check with my recruiter on this. Anyway, I've also devised some ideas for blog posts for as many topics as possible. Let's continue.
The coding and algorithm interviews
Show good understanding of JavaScript, its APIs, Object Oriented Design and Programming, how to test code, and how to come up with corner cases and edge cases for code. At a Google interview, there's a big focus on showing conceptual understanding rather than memorizing code. You'll need to double down on concept rather than implementation - and ensure fundamentals are well articulated.
My planned posts here are:
- Know at least one programming language well (JavaScript, its APIs) (#javascript)
- JavaScript and object oriented programming (#javascript)
- JavaScript and how to test code (coming up with corner and edge cases) (#javascript)
Algorithms
Bottom-up versus top-down algorithms, complexity analysis, how to improve/change it. These include sorting, search and binary search, divide-and-conquer, dynamic programming/memorization, greediness and recursion. Yea, it's a big list. They specifically ask candidates to be ready to discuss complex algorithms like Dijkstra and A*. So we'll practice that here.
Planned posts:
- Bottom-up versus top-down algorithms (#algorithms)
- Complexity analysis: an introduction (#complexity-analysis)
- Dijkstra and A* (#famous-algorithms)
Sorting, Data structures, Graphs, Recursion
Planned posts:
- The trade-off between QuickSort/MergeSort/HeapSort (#sorting)
- Data structures: algorithms that go along with each (#data-structures)
- Representing a graph in-memory: pointers, matrix, adjacency list and their pros/cons (#graphs)
- Computational complexity and tradeoffs for basic graph traversals, BFS and DFS (#graphs)
- How recursion can solve iterative problems more elegantly (#recursion)
I skipped Mathematics. I will probably focus on completing some n-choose-k problems on my own time.
The technical front end interview
Onto the front end part. The ask here is that you're prepared to cover topics related to front end latency and understanding idiomatic JavaScript. Additionally, candidates must articulate strengths/shortcomings for a diverse range of topics, from web security, browser technology to JavaScript inheritance.
I would like to keep my front end posts interesting. Perhaps explore demos. I do want to be very careful as some of these topics get hairy very quickly. Hopefully I can find a proper pedagogy while properly managing rabbit holes. I think not giving up until we ask really good questions and make them fun posts is essential. So I probably need to start drafting these as early as possible. Perhaps a good structure is Who, What, Where, When, and How - to cover historical events and rudimentary examples. For the security ones, if we need to work with older versions of Node.js/Express to devise a real attack, that would be cool. Getting a tip from a Googler on what's priority here would be nice. Regardless, it'll be important to stick to basics and perhaps leave room to do a part 2 series piece afterwards.
Planned posts:
- Front end latency (#frontend, #browser)
- Understanding idiomatic JavaScript (#javascript)
- Cross-site scripting & Cross-site request forgery (#web-security)
- Prototypical inheritance (#javascript)
- DOM API & manipulation (#dom)
- CSS manipulation (#css)
- Browser / DOM events & event handling (#dom, #browser)
- XHR request & HTTP headers (#browser)
- JavaScript closures (#javascript)
The front-end design interview
For this, they want to test your combined knowledge, theory, experience and judgement towards solving real-world engineering problems. They list the following as sample topics: web app, mobile app and API design (where the front/back meet).
Planned posts:
Solving for real world front-end engineering problems
Designing APIs (where the front end and back end meet)
Lastly, other important topics (yes, Google's big papers)
If there's time (I can't promise since I'd assume these be more related to Google's General Interview Track for back end engineers), it would be nice to cover the famous papers and projects: The Google File System, Bigtable, MapReduce, Google Spanner and Google Chubby. We'll see. Wish me luck!
