Previously at Uber, Skyscanner, Skype/Microsoft. I love to help people grow and share what I learned. I write longer articles on software engineering at blog.pragmaticengineer.com.
This is a nice overview of the Google interview process - thanks a lot, Emma!
As a hiring manager now at Uber including for frontend, and talking with several other hiring manager friends at other larger tech companies (Amazon, Facebook, Netflix etc) the frontend interview process is not too different for larger tech companies and the tips shared here would apply at those places as well.
Some places - like Amazon or Uber - also have a Bar Raiser round onsite, that is similar to the "Teamwork, Process & Culture Fit Interview" described here.
The main suggestion I have for anyone preparing for interviews is to go back to basics on web development basics (like the topics Emma listed very well on the Front-End Interviews) and to spend time to prepare for data structures interviews and solving simple - not necessarily tricky - algorithms questions. Most places don't ask this to test if you have advanced algorithm knowledge. They do this, to see how you can map a problem, turn it into code with a simple solution (the brute force solution), test it, and potentially optimize it. This, second part is something that most people would fail without preparation upfront - preparation that will be useful for the rest of your career, I would add. I would not go deeper than the topics Emma listed: but, I would go deep into them and master these tools. So e.g. being able to implement a BFS or DFS (breadth-first-search or depth-first-search) is something almost all places will expect people to be able to write working code for, if asked. BFS and DFS is especially true for Google, where trees and graphs are a bit of the DNA of the company.
I always wonder why data structures/algorithms is a necessity for almost all places...if you need them, you read/learn/use them. I don't feel any less of a programmer not being able to implement them in minutes, except for the brute force 🤓
I think the main point comes from showing you know something that is easily testable (as algorithms and compleity analysis surely are) for your interviewers, you know?
The point, IMO, is not that you have to know them by heart because that is a skill you gotta know at any given moment. It is the process of learning and the growth that comes from it, and the specific areas of your reasoning those subjects encompass, that they should be trying to test.
In other words, as one of my teachers in primary school used to say: we are not here to teach you History or Mathematics or Chemistry, you're not gonna need all that. We are teaching you how to think, and each one of us [professors] is doing it the way he/she knows best.
Previously at Uber, Skyscanner, Skype/Microsoft. I love to help people grow and share what I learned. I write longer articles on software engineering at blog.pragmaticengineer.com.
I think you misunderstand what I meant by you need to know data structures and algorithms. Where I work, we don't ask you to implement any of these on interviews (some companies do ask this - though a lot more are turning into more practical problems). You need to know them, to be able to solve the type of coding problems that can be understood in 5 minutes and solved in 45 minutes with no framework dependencies. So things testing your problem-solving skills. Though when I learned about them, I implemented them for fun - as they're all pretty simple ones, and it's a fun little challenge to do so.
For places like Google and the like, to pass the interview process, you most likely need to prepare for these - become familiar with how the structures work, cases where they are good solutions, and if you're curious, looking into real-world examples where they are used (e.g. do you know what tree structure is a very popular to use for SQL database indexing and why? It's interesting to learn why and how).
Not knowing these doesn't make you a worse programmer. But you'd probably do worse on the interview than the many other candidates you're competing for that same position at these places where it's competitive to get through each of the rounds, and then getting an offer.
What is the extra information an interviewer gets from the candidate if he/she solves a problem with this lexical knowledge or another one where this knowledge is not needed?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a nice overview of the Google interview process - thanks a lot, Emma!
As a hiring manager now at Uber including for frontend, and talking with several other hiring manager friends at other larger tech companies (Amazon, Facebook, Netflix etc) the frontend interview process is not too different for larger tech companies and the tips shared here would apply at those places as well.
Some places - like Amazon or Uber - also have a Bar Raiser round onsite, that is similar to the "Teamwork, Process & Culture Fit Interview" described here.
The main suggestion I have for anyone preparing for interviews is to go back to basics on web development basics (like the topics Emma listed very well on the Front-End Interviews) and to spend time to prepare for data structures interviews and solving simple - not necessarily tricky - algorithms questions. Most places don't ask this to test if you have advanced algorithm knowledge. They do this, to see how you can map a problem, turn it into code with a simple solution (the brute force solution), test it, and potentially optimize it. This, second part is something that most people would fail without preparation upfront - preparation that will be useful for the rest of your career, I would add. I would not go deeper than the topics Emma listed: but, I would go deep into them and master these tools. So e.g. being able to implement a BFS or DFS (breadth-first-search or depth-first-search) is something almost all places will expect people to be able to write working code for, if asked. BFS and DFS is especially true for Google, where trees and graphs are a bit of the DNA of the company.
Thanks again for this great overview!
Wonderful comment Gergely! Thank you!
I always wonder why data structures/algorithms is a necessity for almost all places...if you need them, you read/learn/use them. I don't feel any less of a programmer not being able to implement them in minutes, except for the brute force 🤓
I think the main point comes from showing you know something that is easily testable (as algorithms and compleity analysis surely are) for your interviewers, you know?
The point, IMO, is not that you have to know them by heart because that is a skill you gotta know at any given moment. It is the process of learning and the growth that comes from it, and the specific areas of your reasoning those subjects encompass, that they should be trying to test.
In other words, as one of my teachers in primary school used to say: we are not here to teach you History or Mathematics or Chemistry, you're not gonna need all that. We are teaching you how to think, and each one of us [professors] is doing it the way he/she knows best.
I think you misunderstand what I meant by you need to know data structures and algorithms. Where I work, we don't ask you to implement any of these on interviews (some companies do ask this - though a lot more are turning into more practical problems). You need to know them, to be able to solve the type of coding problems that can be understood in 5 minutes and solved in 45 minutes with no framework dependencies. So things testing your problem-solving skills. Though when I learned about them, I implemented them for fun - as they're all pretty simple ones, and it's a fun little challenge to do so.
For places like Google and the like, to pass the interview process, you most likely need to prepare for these - become familiar with how the structures work, cases where they are good solutions, and if you're curious, looking into real-world examples where they are used (e.g. do you know what tree structure is a very popular to use for SQL database indexing and why? It's interesting to learn why and how).
Not knowing these doesn't make you a worse programmer. But you'd probably do worse on the interview than the many other candidates you're competing for that same position at these places where it's competitive to get through each of the rounds, and then getting an offer.
I see, but one thing is still not clear.
What is the extra information an interviewer gets from the candidate if he/she solves a problem with this lexical knowledge or another one where this knowledge is not needed?