一、The Interview Process
At most of the top tech companies (and many other companies), algorithm and coding problems form the largest component of the interview process. Think of these as problem-solving questions. The interviewer is looking to evaluate your ability to solve algorithmic problems you haven't seen before.
Very often, you might get through only one question in an interview. You should do your best to talk out loud throughout the problem and explain your thought process. Your interviewer might jump in sometimes to help you; let them. It's normal and doesn't really mean that you're doing poorly. (That said, of course not needing hints is even better.)
Your interviewer will make an assessment of your performance, usually based on the following:Analytical skills、Coding skills、Technical knowledge/Computer Science fundamentals、Experience、Culture fit/Communication skills。
Why?
False negatives are acceptable.
Problem-solving skills are valuable.
Basic data structure and algorithm knowledge is useful.
Whiteboards let you focus on what matters.
Whiteboards let you focus on what matters.
But it's not for everyone or every company or every situation.
How Questions are Selected
The questions asked this year at Google do not really differ from those asked three years ago. In fact, the questions asked at Google generally don't differ from those asked at similar companies (Amazon, Facebook, etc.) .
There are some broad differences across companies. Some companies focus on algorithms (often with some system design worked in), and others really like knowledge-based questions. But within a given category of question, there is little that makes it "belong" to one company instead of another. A Google algorithm question is essentially the same as a Facebook algorithm question.
It's All Relative
Interviewers assess you relative to other candidates on that same question by the same interviewer. It's a relative comparison.
Frequently Asked Questions
I didn't hear back immediately after my interview. Am I rejected?
No. If you haven't heard back from a company within 3 - 5 business days after your interview, check in (politely) with your recruiter.
Can I re-apply to a company after getting rejected?
Almost always, but you typically have to wait a bit (6 months to a 1 year).
二、Behind the Scenes
Once you are selected for an interview, you usually go through a screening interview. This is typically conducted over the phone.
Don't let the name fool you; the "screening" interview often involves coding and algorithms questions, and the bar can be just as high as it is for in-person interviews. If you're unsure whether or not the interview will be technical, ask your recruiting coordinator what position your interviewer holds (or what the interview might cover). An engineer will usually perform a technical interview.
In an on-site interview round, you usually have 3 to 6 in-person interviews. One of these is often over lunch. The lunch interview is usually not technical, and the interviewer may not even submit feedback. This is a good person to discuss your interests with and to ask about the company culture.Your other interviews will be mostly technical and will involve a combination of coding, algorithm, design/architecture, and behav- ioral/experience questions.
Most companies get back after about a week with next steps
The Microsoft Interview
Microsoft wants smart people. Geeks. People who are passionate about technology. You probably won't be tested on the ins and outs of c++ APls, but you will be expected to write code on the board.
The Amazon Interview
Definitely Prepare:
Amazon cares a lot about scale. Make sure you prepare for scalability questions. You don't need a back- ground in distributed systems to answer these questions. See our recommendations in the System Design and Scalability chapter.
Additionally, Amazon tends to ask a lot of questions about object-oriented design. Check out the Object- Oriented Design chapter for sample questions and suggestions.
The Google Interview
To extend an offer, the HC wants to see at least one interviewer who is an "enthusiastic endorser:' In other words, a packet with scores of 3.6,3.1,3.1 and 2.6 is better than all 3.1s.
Definitely Prepare:
As a web-based company, Google cares about how to design a scalable system. So, make sure you prepare for questions from System Design and Scalability.
Google puts a strong focus on analytical (algorithm) skills, regardless of experience. You should be very well prepared for these questions, even if you think your prior experience should count for more.
The Apple Interview
Definitely Prepare:
If you know what team you're interviewing with, make sure you read up on that product. What do you like about it? What would you improve? Offering specific recommendations can show your passion for the job.
What's Unique:
Apple does two-on-one interviews often, but don't get stressed out about them- it's the same as a one-on-
one interview!
Also, Apple employees are huge Apple fans.You should show thissame passion in your interview.
The Facebook Interview
Once selected for an interview, candidates will generally do one or two phone screens. Phone screens will be technical and will involve coding, usually an online document editor.
Each interviewer is given a"role"during the on-site interviews, which helps ensure that there are no repeti- tive questions and that they get a holistic picture of a candidate.These roles are:
Behavioral ("Jedi"): This interview assesses your ability to be successful in Facebook's environment. Would you fit well with the culture and values? What are you excited about? How do you tackle chal- lenges? Be prepared to talk about your interest in Facebook as well. Facebook wants passionate people. You might also be asked some coding questions in this interview.
Coding and Algorithms ("Ninja"): These are your standard coding and algorithms questions, much like what you'll find in this book. These questions are designed to be challenging.You can use any program- ming language you want.
Design/Architecture ("Pirate"): For a backend software engineer, you might be asked system design questions. Front-end or other specialties will be asked design questions related to that discipline. You should openly discuss different solutions and their tradeoffs.
You can typically expect two "ninja" interviews and one "jedi" interview. Experienced candidates will also usually get a "pirate" interview.
Definitely Prepare:
The youngest of the "elite" tech companies, Facebook wants developers with an entrepreneurial spirit. In your interviews, you should show that you love to build stuff fast.
They want to know you can hack together an elegant and scalable solution using any language of choice. Knowing PHP is not especially important, particularly given that Facebook also does a lot of backend work in C++, Python, Erlang, and other languages.
The Palantir Interview
Definitely Prepare:
Palantir values hiring brilliant engineers. Many candidates report that Palantir's questions were harder than those they saw at Google and other top companies.This doesn't necessarily mean it's harder to get an offer (although it certainly can); it just means interviewers prefer more challenging questions. If you're inter- viewing with Palantir, you should learn your core data structures and algorithms inside and out. Then, focus on preparing with the hardest algorithm questions.
Brush up on system design too if you're interviewing for a backend role. This is an important part of the process.
What's Unique:
A coding challenge is a common part of Palantir's process. Although you'll be at your computer and can look up material as needed, don't walk into this unprepared. The questions can be extremely challenging and the efficiency of your algorithm will be evaluated.Thorough interview preparation will help you here. You can also practice coding challenges online at HackerRank.com.
三、Special Situations
Experienced Candidates
More experienced engineers might see slightly less focus on algorithm questions-but only slightly
If a company asks algorithm questions to inexperienced candidates, they tend to ask them to experienced candidates too. Rightly or wrongly, they feel that the skills demonstrated in these questions are important for all developers.
The exception to this rule is system design and architecture questions, as well as questions about your resume. Typically, students don't study much system architecture, so experience with such challenges would only come professionally.Your performance in such interview questions would be evaluated with respect to your experience level. However, students and recent graduates are still asked these questions and should be prepared to solve them as well as they can.
Additionally, experienced candidates will be expected to give a more in-depth, impressive response to questions like, "What was the hardest bug you've faced?" You have more experience, and your response to these questions should show it.
Testers and SDETs
Product(and Program) Management
Handling Ambiguity、Customer Focus (Attitude)、Customer Focus (Technical Skills)、Multi-Level Communication、Passion for Technology、Teamwork I Leadership
Dev Lead and Managers
Strong coding skills are almost always required for dev lead positions and often for management positions as well. If you'll be coding on the job, make sure to be very strong with coding and algorithms-just like a dev would be. Google, in particular, holds managers to high standards when it comes to coding.
In addition, prepare to be examined for skills in the following areas:Teamwork I Leadership、Prioritization、Communication、"Getting Things Done"
Startups
The Application Process
Many startups might post job listings,but for the hottest startups,often the best way in is through a personal referral. This reference doesn't necessarily need to be a close friend or a coworker. Often just by reaching out and expressing your interest, you can get someone to pick up your resume to see if you're a good fit.
Visas and Work Authorization
Unfortunately, many smaller startups in the U.s. are not able to sponsor work visas. They hate the system as much you do, but you won't be able to convince them to hire you anyway. If you require a visa and wish to work at a startup, your best bet is to reach out to a professional recruiter who works with many startups (and may have a better idea of which startups will work with visa issues), or to focus your search on bigger startups .
Resume Selection Factors
Startups tend to want engineers who are not only smart and who can code, but also people who would work well in an entrepreneurial environment. Your resume should ideally show initiative.What sort of proj- ects have you started?
Being able to "hit the ground running" is also very important; they want people who already know the language of the company.
The Interview Process
In contrast to big companies, which tend to look mostly at your general aptitude with respect to software development, startups often look closely at your personality fit, skill set, and prior experience.
In addition to the above areas, the coding and algorithms questions that you see in this book are also very common.
Acquistions and Acquihires
For Interviewers
四、Before the Interview
1.Getting the Right Experience
If you're trying to move from a lesser-known company to one of the "biggies;' or from testing/IT into a dev role, the following advice will be useful:Shift Work Responsibilities More Towards Coding、Use Your Nights and Weekends
All of these boil down to the two big things that companies want to see: that you're smart and that you can code. If you can prove that, you can land your interview.
In addition, you should think in advance about where you want your career to go. If you want to move into management down the road, even though you're currently looking for a dev position, you should find ways now of developing leadership experience.
2.Writing a Great Resume
Resume screeners look for the same things that interviewers do. They want to know that you're smart and that you can code.
Appropriate Resume Length
In the US, it is strongly advised to keep a resume to one page if you have less than ten years of experience.More experienced candidates can often justify 1.5 - 2 pages otherwise.
Employment History
Your resume does not-and should not-include a full history of every role you've ever had. Include only the relevant positions-the ones that make you a more impressive candidate.
Writing STrong Bullets:
For each role, try to discuss your accomplishments with the following approach: "Accomplished X by imple- menting Y which led to Z:' (使用Y实现了X，从而达到了Z效果）.Here's an example:"Reduced object rendering time by 75% by implementing distributed caching, leading to a 10% reduc- tion in log-in time:'
Not everything you did will fit into this approach, but the principle is the same: show what you did, how you did it, and what the results were. Ideally, you should try to make the results "measurable" somehow.
Projects
The projects should include your 2 - 4 most significant projects. State what the project was and which languages or technologies it employed. You may also want to consider including details such as whether the project was an individual or a team project, and whether it was completed for a course or indepen- dently. These details are not required, so only include them if they make you look better.Independent projects are generally preferred over course projects, as it shows initiative.
Programming Languages and Software
Software:who care!
Languages:like this:
Languages: Java (expert), C++ (proficient), JavaScript (prior experience).
Advice for Non-Native English Speakedrs and Internationals
Some companies will throw out your resume just because of a typo. Please get at least one native English speaker to proofread your resume.
Additionally, for US positions, do not include age, marital status, or nationality.This sort of personal informa- tion is not appreciated by companies, as it creates a legal liability for them.
Beware of (Potential) Stigma
Where possible, try to truly diversify. The languages in the cluster of {Python, Ruby, and JavaScript} are somewhat similar to each other. It's better if you can learn languages that are more different, like Python, C++, and Java.
3.Preparation Map
五、Behavioral Questions
1.Interview Preparation Grid
Go through each of the projects or components of your resume and ensure that you can talk about them in detail. Filling out a grid like this may help:
Along the top, as columns, you should list all the major aspects of your resume, including each project, job, or activity. Along the side, as rows, you should list the common behavioral questions.
What are your weaknesses?
When asked about your weaknesses, give a real weakness! Answers like "My greatest weakness is that I work too hard" tell your interviewer that you're arrogant and/or won't admit to your faults. A good answer conveys a real, legitimate weakness but emphasizes how you work to overcome it.
What questions should you ask the interviewer?
Most interviewers will give you a chance to ask them questions. The quality of your questions will be a factor, whether subconsciously or consciously, in their decisions. Walk into the interview with some ques- tions in mind.
You can think about three general types of questions.
Genuine Questions:1. "What is the ratio of testers to developers to program managers? What is the interaction like? How does project planning happen on the team?" 2. "What brought you to this company? What has been most challenging for you?" 3.你每天有多少时间花在写代码上？ 4.你一周要开几次会？
Insightful Questions：1. "I noticed that you use technology X. How do you handle problem Y?" 2. "Why did the product choose to use the X protocol over the Y protocol? I know it has benefits like A, B, C, but many companies choose not to use it because of issue 0:'
Passion Questions：1."I'm very interested in scalability,and I'd love to learn more about it.What opportunities are there at this company to learn about this?" 2. "I'm not familiar with technology X, but it sounds like a very interesting solution. Could you tell me a bit more about how it works?"
2.Know Your Technical Projects
As part of your preparation, you should focus on two or three technical projects that you should deeply master. Select projects that ideally fit the following criteria:
1.The project had challenging components (beyond just "learning a lot"). 2.You played a central role (ideally on the challenging components).3.You can talk at technical depth.
For those projects, and all your projects, be able to talk about the challenges, mistakes, technical decisions,
choices of technologies (and tradeoffs of these), and the things you would do differently. You can also think about follow-up questions,like how you would scale the application.
3.Responding to Behavioral Questions
Behavioral questions allow your interviewer to get to know you and your prior experience better. Remember the following advice when responding to questions.
Be Specific,Not Arrogant
Arrogance is a red flag, but you still want to make yourself sound impressive. So how do you make yourself sound good without being arrogant?By being specific!
Specificity means giving just the facts and letting the interviewer derive an interpretation. For example, rather than saying that you "did all the hard parts;' you can instead describe the specific bits you did that were challenging.
Limit Details
When a candidate blabbers on about a problem, it's hard for an interviewer who isn't well versed in the subject or project to understand it.
Stay light on details and just state the key points. When possible, try to translate it or at least explain the impact. You can always offer the interviewer the opportunity to drill in further: "By examining the most common user behavior and applying the Rabin-Karp algorithm, I designed a new algorithm to reduce search from 0 (n) to 0 (log n) in 90% of cases. I can go into more details if you'd like:'
Focus on Yourself,Not Your Team
Give Structured Answers
There are two common ways to think about structuring responses to a behavioral question: nugget first and S.A.R. These techniques can be used separately or together.
4.So,tell me about yourself
Structure
A typical structure that works well for many people is essentially chronological, with the opening sentence describing their current job and the conclusion discussing their relevant and interesting hobbies outside ofwork (ifany).
1.Current Role[Headline Only]
2.College
3.Post College & Onwards
4.Current Role [Details]
5.Outside of Work
6.Wrap Up
Hobbles
Think about how to best frame your hobby though. Do you have any successes or specific work to show from it (e.g., landing a part in a play)? Is there a personality attribute this hobby demonstrates?
Sprinkle in Shows of Successes
In the above pitch, the candidate has casually dropped in some highlights of his background.
• He specifically mentioned that he was recruited out of Microworks by his old manager, which shows that he was successful at Amazon.
• He also mentions wanting to be in a smaller environment, which shows some element of culture fit (assuming this is a startup he's applying for).
He mentions some successes he's had, such as launching a key part of AWS and architecting a scalable system.
• He mentions his hobbies, both of which show a drive to learn.
When you think about your pitch, think about what different aspects of your background say about you. Can you can drop in shows of successes (awards, promotions, being recruited out by someone you worked with, launches, etc.)? What do you want to communicate about yourself?
六、Big O
七、Technical Questions
1.How to Prepare
For each problem in this book (and any other problem you might encounter), do the following:1.Try to solve the problem on your own、2.Write the code on paper、3.Test your code-onpaper、4.Type your paper code as-is into a computer.
In addition, try to do as many mock interviews as possible. You and a friend can take turns giving each other mock interviews.
2.What You Need To Know
The sorts of data structure and algorithm questions that many companies focus on are not knowledge tests. However, they do assume a baseline of knowledge.
Core Data Structures,Algorithms,and Concepts
Most interviewers won't ask about specific algorithms for binary tree balancing or other complex algo- rithms. Frankly, being several years out of school, they probably don't remember these algorithms either.
You're usually only expected to know the basics. Here's a list of the absolute, must-have knowledge:
For each of these topics, make sure you understand how to use and implement them and, where applicable,the space and time complexity.
Practicing implementing the data structures and algorithm (on paper, and then on a computer) is also a great exercise. It will help you learn how the internals of the data structures work, which is important for many interviews.
Did you miss that paragraph above? It's important. If you don't feel very, very comfortable with each of the data structures and algorithms listed, practice implementing them from scratch.
In particular, hash tables are an extremely important topic. Make sure you are very comfortable with this data structure.
Powers of 2 Table
For example, you could use this table to quickly compute that a bit vector mapping every 32-bit integer to a boolean value could fit in memory on a typical machine.There are 232 such integers. Because each integer takes one bit in this bit vector, we need 232 bits (or 229 bytes) to store this mapping.That's about half a giga- byte of memory, which can be eaSily held in memory on a typical machine.
If you are doing a phone screen with a web-based company, it may be useful to have this table in front of you.
3.Walking Through a Problem
The below map/flowchart walks you through how to solve a problem. Use this in your practice. You can download this handout and more at CrackingTheCodinglnterview.com.
What to Expect
Interviews are supposed to be difficult. If you don't get every- or any-answer immediately, that's okay! That's the normal experience, and it's not bad.
Listen for guidance from the interviewer. The interviewer might take a more active or less active role in your problem solving. The level of interviewer participation depends on your performance, the difficulty of the question, what the interviewer is looking for, and the interviewer's own personality.
When you're given a problem (or when you're practicing). work your way through it using the approach below.
1.Listen Carefully
2.Draw an Example
3.State a Brute Force
4.Optimize
Look for any unused information.Use a fresh example.Solve it "incorrectly".Make time vs.Precompute information.Use a hash table.Think about the best conceivable runtime
Walk through the brute force with these ideas in mind and look for BUD (page 67).
5.Walk Through
6.Implement
7.Test
4.Optimize & Solve Technique #1:Look for BUG
5.Optimize & Solve Technique #2:DIY
6.Optimize & Solve Technique #3:Simplify and Generalize
7.Optimize & Solve Technique #4:Base Case and Build
8.Optimize & Solve Technique #5:Data Structure BrainStorm
9.Best Concelvable Runtime
Considering the best conceivable runtime can offer a useful hint for some problem.
The best conceivable runtime is, literally, the best runtime you could conceive of a solution to a problem having. You can easily prove that there is no way you could beat the BCR.
For example, suppose you want to compute the number of elements that two arrays (of length A and B) have in common.You immediately know that you can't do that in better than O(A + B) time because you have to "touch" each element in each array. 0 (A + B) is the BCR.
An Example of How to Use BCR
10.Handing Incorrect Answers
One of the most pervasive-and dangerous-rumors is that candidates need to get every question right. That's not quite true.
11.When You've Heard a Question Before
If you've heard a question before, admit this to your interviewer. Your interviewer is asking you these ques- tions in order to evaluate your problem-solving skills. If you already know the question, then you aren't giving them the opportunity to evaluate you.
Additionally, your interviewer may find it highly dishonest if you don't reveal that you know the question. (And, conversely, you'll get big honesty points if you do reveal this.)
12.The "Perfect" Language for Interviews
At many of the top companies, interviewers aren't picky about languages. They're more interested in how well you solve the problems than whether you know a specific language.
Other companies though are more tied to a language and are interested in seeing how well you can code in a particular language.
If you're given a choice of languages, then you should probably pick whatever language you're most comfortable with.
That said, if you have several good languages, you should keep in mind the following.
13.What Good Coding Looks Like
Correct: The code should operate correctly on all expected and unexpected inputs.
Efficient: The code should operate as efficiently as possible in terms of both time and space.
Simple: If you can do something in 10 lines instead of 100, you should. Code should be as quick as possible for a developer to write.
Readable: A different developer should be able to read your code and understand what it does and how it does it. Readable code has comments where necessary, but it implements things in an easily understandable way. That means that your fancy code that does a bunch of complex bit shifting is not necessarily good code.
Maintainable: Code should be reasonably adaptable to changes during the life cycle of a product and should be easy to maintain by other developers, as well as the initial developer.
Use Data Structures Generously
Appropriate Code Reuse
Modular
Flexible and Robust
Error Checking
14.Don't Give Up!
I know interview questions can be overwhelming, but that's part of what the interviewer is testing. Do you rise to a challenge, or do you shrink back in fear? It's important that you step up and eagerly meet a tricky problem head-on. After all, remember that interviews are supposed to be hard. It shouldn't be a surprise when you get a really tough problem.
For extra "points;' show excitement about solving hard problems.
八、The Offer and Beyond
1.Handing Offers and Rejection
Offer Deadlines and Extensions
When companies extend an offer, there's almost always a deadline attached to it. Usually these deadlines are one to four weeks out. Ifyou're still waiting to hear back from other companies, you can ask for an exten- sion. Companies will usually try to accommodate this, if possible.
Declining an Offer
When you decline an offer, provide a reason that is non-offensive and inarguable. For example, if you were declining a big company for a startup, you could explain that you feel a startup is the right choice for you at this time. The big company can't suddenly "become" a startup, so they can't argue about your reasoning.
Hading Rejection
When you do get the unfortunate call, use this as an opportunity to build a bridge to re-apply. Thank your recruiter for his time, explain that you're disappointed but that you understand their pOSition, and ask when you can reapply to the company.
You can also ask for feedback from the recruiter. In most cases, the big tech companies won't offer feed- back, but there are some companies that will. It doesn't hurt to ask a question like, "Is there anything you'd suggest I work on for next time?"
2.Evaluation the Offer
The Financial Package、Career Development、Company Stability、The Happiness Factor
3.Negotiation
Just Do it、Have a Viable Alternatived、Have a Specific"Ask"、Overshoot、Think Beyond Salary、Use Your Best Medium
4.On the Job
Set a Timeline、Build Strong Relationships、Ask for What You Want、Keep Interviewing
九、Interview Questions
join us at www.CrackingTheCodingInterview.com to download the complete solutions,contribute or view solutions in other programming languages,discuss problems from this book with other readers,ask questions,report issues,view this book's errata,and seek additional advice.
