As always, your recruiter should be your first source of information. Your recruiter is your champion through the process and is working to get you hired. Ask them any question that you need.

Also, there are a lot of resources out there about how to pass a software engineering interview or more specifically, a front-end interview. I’m going to focus on what is specific to Google in 2020 in my answer.

1. All coding questions come from a database. Any question which has leaked is promptly flagged and won’t be asked again. There’s virtually no chance of getting a question that you know. So, there are diminishing returns in cramming LeetCode questions. You should stop at “I think I know how to solve this kind of problem”.
2. No trick questions - another guarantee from the database. No specific, pre-existing knowledge is needed. The simplest approach is usually the right one and if not, it will certainly get you closer to the solution. Front-end coding questions are meant to be solved in javascript, not typescript or angular or anything extra.
3. This is to the interviewer discretion but candidates normally have 35 minutes to solve the problem. Managing time is the most important/difficult aspect of the interview. It’s not certain that you have a chance to make a second pass on your solution. To that end:
1. try to form a complete plan of what you want to do before starting coding. You may want to write it in pseudocode or something or just say it loud. when working on your plan, try to come up with a few test cases and include edge cases.
   
   It’s harder to do that without a white board. you may want to keep some writing material at hand. you can also write in a comment in the VIP.
2. focus on the JS syntax that is quickest to write. Typically the data structure you want to use is the plain old javascript object, maybe the array, maybe the string. If you have a case where using a set or a map actually simplifies things and make them faster to write, more power to you but this is unlikely, so don’t try to do anything extra fancy. Likewise, don’t use classes unless this is really necessary or this is actually harder to write JS without classes to you, as there is a time overhead.
4. Virtual Interview Platform (VIP) - as of today, all coding interviews are remote and all use the VIP, which is a lightweight coding environment. In the VIP candidates can choose their programming language and get syntax highlighting, plus see a clock that times the exercise, but the code is not going to run.
   
   The auto-formatting capacity of the VIP is limited compared to full-fledged coding editors, but don’t let that bog you down. Interviewers don’t care about spacing, they (mostly) don’t care about incorrect method names (we will note that but it doesn’t matter much in the grand scheme of things). Unfortunately, it is tempting to spend a lot of time tweaking these things as opposed to just solve the problem. And again, time is the most precious resource on the interview.
5. “test” your code. test is in quotes as your code won’t actually run. Write your code defensively, check that the input is well formed and have a flow for edge cases. When you are done, try to see what would happen with several test cases.
6. clean code. Clear variable names are useful, code that can be isolated in its own function, too. This has 2 benefits to you. First, many candidates get confused with their own variable names and lose a ton of time. Conversely, good variable names prove that the candidate has understood the question well. Also, the implementation of helper functions can be delayed (or even skipped) especially if they do something trivial, which means more time to you.

2022 edit re JavaScript vs TypeScript. TS is also an option for front-end questions. If you selected TS as your favorite language, do use it but if you selected JS, I still don’t recommend doing this in TypeScript “for extra credits”.