The original manuscript of this article is sent to me by a reader. I think it's really good, so I sorted it out by myself. At the back of the article, I also provide the address of the PDF offline version. (run
First of all, let's look at the requirements of Google engineers: college, CS (Computer Science, Computer Science) professional background, doctoral degree with strong technical skills?
Is it particularly difficult to be an engineer at Google? John Washam tells you: No, you can teach yourself for 8 months!
John Washam wanted to be a Google software engineer, but without a CS background, he had to work hard to get there.
Over the course of eight months, he spent thousands of hours reading books, writing code, and watching CS lectures as he fought his way up the ranks.
Instead of going to Google, he ended up making a million a year as a technologist at Amazon's AWS (which is really good).
What's more, he has compiled a tutorial on his lessons, which has garnered more than 140K + stars since being launched on GitHub.
The project address is as follows:
Little brother said: "even without the face dream of Google, but this tutorial, also be a good enrichment of their own."
The young man's initial goal was to "get into" Google, so he taught himself 8-12 hours a day for more than eight months. While studying, I put together this self-study project.
The younger brother said:
No matter which software company you're interviewing for, this program will prepare you well for the job, including tech giants like Amazon, Facebook, Google and Microsoft.
Next, let's follow the footsteps of the little brother to learn about the interview guide.
Then start to learn something about computers, such as how a computer works with a program, how a compiler works, and how floating point numbers are stored.
Then there's algorithmic complexity, big-O (a mathematical symbol used to describe the asymptotic behavior of a function), asymptotic analysis, data structures (arrays, linked lists, stacks, queues, hash tables, graphs). And binary search, bitwise operation.
There is a lot of knowledge about trees. Let me draw a mind map:
Let's move on to the mind map:
In addition, there are recursion, dynamic programming, combination and probability, NP (set of non-deterministic polynomials, one of the most important sets in computing theory) and NP-complete and approximate algorithms, caching, threads and processes, and system design.
So much knowledge, do you feel a little muddled?
Take a look at my experience:
1) It's important to recognize that you can't remember everything at once.
2) Make flashcards of the points to be reviewed: normal and coded, similar to memorizing words. Then take notes on flashcards and ask yourself a few times before you really know how to solve the problem. Repeat questions to help you remember the knowledge.
3) Review, review, review. Every half hour of programming, take a break and review your flashcards.
4) Focus. In the process of learning, there are often many distractions that occupy our precious time. As a result, focus and concentration are very difficult.
Once you've learned enough, you can prepare for the interview. The first step of course is to have a good resume, so that you can win valuable interview opportunities.
Steve Yagge offers 10 tips to help you create a great resume.
1) In the beginning, no one cares about you, so don't talk about your hopes, goals, dreams, and ambitions on your resume.
2) Try to use plain text, don't be flashy.
3) Remember to check for typos. Some English terms must be case sensitive.
4) Don't write about what you were involved in, write about what you actually did.
5) Don't exaggerate yourself.
6) Don't list unimportant credentials on your resume.
7) Please don't say "proficient" easily.
8) Don't sell yourself short. Be confident.
9) Don't write anything boring.
10) Seek truth from facts.
Steve Yagge has worked at Amazon and Google, so his advice is worth following.
Here are 20 questions you might be asked during an interview:
- Why do you want this job?
- What's the most difficult problem you've ever solved?
- What is the biggest challenge you have faced?
- What's the best or worst design you've ever seen?
- Suggest improvements to a Google product.
- How do you work best as an individual and as part of a team?
- What skills or experience do you have that are essential to your role? Why is that?
- What do you enjoy most about a job or a project?
- What was the biggest challenge you faced on a job or project?
- What's the worst Bug you've ever had on a job or a project?
- What did you learn from a particular job or project?
- What could you have done better in a particular job or project?
Your best bet is to have two or three answers for each question. You can tell your answer in the form of a story. The interviewer will like it better.
After you've answered all the questions, it doesn't mean it's all over. If the interviewer asks, "Do you have any questions? Don't say what's wrong with you! Here are some questions to try:
- How big is the team?
- What is the development cycle like? Will you use Waterfall flow/EXTREME Programming/Agile development?
- Do you often work overtime to meet deadlines? Or is it elastic?
- How to select technology in the team?
- How many meetings per week on average?
- Do you think the work environment helps employees concentrate?
- What are you doing now?
- Do you like these things?
- What are the deadlines?
If you've landed your dream job, congratulations! Of course, this doesn't mean it's over, you still need to keep learning, and getting a job is just a new beginning.
The following are recommended for your further study:
Of course, there's a reason why he's so good.
Since I was in high school, I've been learning programming, BASIC, back in the '90s. After graduating from college with a degree in economics, he first served two years in the military, stationed in South Korea.
After his retirement, he stayed in Korea to teach English, and suddenly found that in the years he had been away from CS, there were too many new technologies and tools to support a career as a programmer.
Finally, in 2001, he became a web developer, starting his 19-year career as a code farmer.
As of 2017, John has had a very successful career: he has worked for large and small companies, built and managed project teams, managed and expanded startups, and founded three software companies himself, two of which are still in operation.
According to xiao Ge's words, the more than ten years of work experience has trained him into a qualified programmer, an excellent product manager, a CEO, a marketing sales.
But his goal is more than that. His dream was to work at Google as a software engineer, improving himself on a team full of intelligence and creativity.
At first, he thought his experience would be an easy way to get the job, but after getting Google's interview questions, he realized he was too short.
A good software engineer should be proficient in data structures and algorithms, assembly language, memory design, etc., and also consider the impact of code and program structure on the machine in the application scenario.
So he taught himself how to code, using a Google test as a guide. And created "Project 9894" on GitHub, because Google was founded on September 4, 1998. Later, the project was renamed as "Coding Interview University".
Combined with his own learning experience, I give three suggestions for self-learning programming.
1) Ask early and plan early. Don't take things for granted
My biggest lesson is that I spend too much time learning things I don't need. For example, I once read 1000 pages of C++ in 3 weeks, but ended up using Python for interviews and work.
This example does not mean that C++ is unnecessary. Instead, it emphasizes that you need to gather information ahead of time and plan ahead to allocate your study time to different projects to improve your efficiency. Don't say "I think... .
2) When learning, videos are more effective than books
When you first learn, the video is like a teacher, giving you a quick guide. But if you want to go deep, you have to go deep through reading, and spare time is also very important.
Repetition is the key to memory formation, and as we mentioned above, I recommend using memory cards.
He made 1,792 electronic memory cards for himself and used them whenever he had free time -- in supermarket queues, on buses, on the subway, etc.
The younger brother said that now he has fully mastered the basic skills of software engineering, and he is not afraid of any challenge in the work, and the day of self-leap is getting closer and closer.
For us ordinary people, we should also be like the little brother, identify a goal, then make a plan, work hard, and finally god rewards those who work hard.
He may be a fan of the 10,000-hour rule, but even counting his 12-hour days over eight months (31 days a month), that's 2,976 hours -- far from 10,000 hours.
However, after eight months with a firm goal, he was successfully accepted by a big company (although not Google, the average annual salary of amazon software engineers is over one million RMB).
It's one of the most inspiring stories I've seen on GitHub, and that's why I want more people to see it, and I sincerely hope that more people will create their own stories because of this experience and sharing.
There are many jokes about "from entry to give up", but there are also people "from entry to a million annual salary".
Cease to struggle and you cease to live
PS: Take a look at the partial table of contents of this 140K + star interview guide:
Really good, posted online address, from the rare earth mining translation:
I know some of you will like the offline version of GitHub because it can be slow to open, so I have kindly arranged the PDF version of the address:
Link: pan.baidu.com/s/1tOyMq3sG... The extracted code: om0i
By the way, when you meet a good resource, you can make it eat ashes, and at the same time, you can learn a little, you can earn a little, right? Knowledge is infinite, but if we learn just a little bit more than everyone else, is it beyond us?
Like it, hope more people can see it!