In order to get to work at Facebook, I've been ready for years.

(a) In order to work in Silicon Valley, I have been preparing for many years

When I was studying computer science at a university in Australia, I always imagined that I would be a software engineer in Silicon Valley in the future. I hope I can go to work in the technology industry's Innovation center Silicon Valley in the future. This goal has driven me, and it has enabled me to be more focused on preparing for the interview.

In order to learn better, I quit my job as Chief iOS engineer at a great company in Melbourne and then returned to Perth, my hometown city. In Perth, I started preparing for a Silicon Valley company interview. I know the interview preparation will be a very difficult and arduous task.

If you tell a group of software engineers about the process of interviewing, many of these engineers will disagree with the usual interview methods. A lot of the argument comes from the idea that solving an algorithmic problem on a whiteboard actually doesn't really represent a software engineer's ability to perform day-to-day tasks in actual work.

I'm not going to discuss this topic in this article. Instead, I will explore different types of interview practices from the perspective of the candidate. At the same time, I will also share what I learned during the interview process.

(b) interviewing is a skill

In the course of the interview I prepared, I always knew that the interview was very challenging. But it wasn't until I was tortured by the first interview that I knew the interview was so difficult.

Before the interview, I used a number of paid and free services that would allow people with industry experience to conduct code and whiteboard mock interviews over the phone. This kind of interview simulation exercise is very helpful to me in dealing with the pressure of the real interview. But then I gradually discovered that the mock interview exercise was only a small part of the actual interview content.

My advice to you is not to interview your dream job until you have accumulated some experience in mock or actual interview. The tension in the interview can be difficult for you to withstand, only through constant practice can overcome this tense mood.

As with many other things in life, constant practice can boost your self-confidence.

(iii) several different types of interviews I have experienced

If you're good enough at the start of a phone interview, you'll have a chance to participate in an on-site interview that could last for a full couple of days. Each interview usually lasts more than 4-6 hours, depending on the company you are interviewing.

In my own interview in Silicon Valley, I conducted a total of 7 on-site interviews, which gave me a unique perspective on the current situation of the interview.

In general, a live interview will cover three main interview topics: Algorithms, architecture design, and behavior, which is what I specialize in and prepare for. However, there are also companies that seem to be out of the ordinary, and they will broaden the scope of the interview to examine more practical skills.

Let's share some of the types of interviews I've been through:

(1) Algorithm interview

This is the most common type of interview. The interviewer will ask you to solve a problem on the whiteboard and evaluate your knowledge of data structures, sorting algorithms, recursion, time/space complexity analysis, patterns, and extreme case identification. In such interviews, you usually come up with a brute force solution, and then try to improve the solution and discuss tradeoffs between different solutions.

This kind of interview is the best type of interview I've ever had, because for 6 consecutive weeks, I practiced every day to solve algorithmic problems on a cheap hanging whiteboard, analyze their time/space complexity, and really understand the results of each line of code written.

Personally, I like the whiteboard algorithm very much, because I don't need to worry about writing a compiler syntax, which allows me to focus on solving the problem at hand. Other people may not like to have an algorithmic interview on the Whiteboard, and for these people, what I'm saying is, if you can keep practicing, it might change their mind.

(2) Architecture design interview

It's a very interesting type of interview, and it's an interview that I seriously underestimate. The interviewer will ask you to design a system on a whiteboard, such as a parking ticket system, a chat communication system, a Twitter information system, and other common systems.

Through this type of interview, the interviewer examines how you can design a system that meets all the requirements and restrictive conditions after you have a broad concept. In this process, candidates are required to ask the correct questions, as these issues will define requirements and restrictive conditions. This kind of interview process is more of a dialogue, you need to draw some charts in the process, even the class structure. All of this is a high-level communication, so you don't need to write any actual code.

Of course, you should be able to guide the communication content so that the interviewer can understand your knowledge of how the system works. If you are a backend engineer, you do not need to explore the details of the client application mechanism unless you have accumulated some expertise and knowledge in that area. I am an iOS engineer, so in this interview I will focus on architectural patterns, functionality modularity, design patterns, rather than talking about how to extend the content of API endpoints.

(3) Behavioral interview

The interviewer will ask you some questions about yourself and how you can handle certain situations. Preparing for this type of interview is not as difficult as preparing a few other types of interviews, but it requires a lot of self-reflection.

Questions that are usually asked include:

How you deal with failure.

What do you think is your biggest weakness?

How you resolve conflicts.

If there is a chance to do it again, what will be the difference between your current practice and the previous one?

I find it hard to screw up this kind of interview, but I've found that a lot of people do have problems with this kind of interview. They try to disguise their strengths as weaknesses, and when they answer questions they only say the answers they think the interviewer will want to hear, and even pass on the responsibility of failing projects to others. This is similar to the following:

"My weakness is that I'm too focused," he said. ”

"The main blame for the project's failure was Jerry, who screwed up most of the work in the project," he said. ”

You know, these interviewers are strictly trained professionals who can easily identify incompetent people and are sensitive to the nonsense lies that the candidate is talking about. They can pass off the unqualified candidates quickly. In the interview process, be sincere, do not play smart, to show enthusiasm for your work, acknowledge your shortcomings, and show the initiative to improve the shortcomings and strong will, only in this way, you can get the favor of the interviewer.

(4) Cultural compatibility

This is often combined with behavioral interviewing, which is primarily about whether you are in line with the company's values. For example, Facebook encourages a hacker-like culture to encourage employees to take bold new ideas and test their ideas, rather than fear breaking stereotypes, the so-called move fast and break things. Airbnb wants to create a world where people can find a sense of belonging anywhere, so they usually look for people with good hospitality skills.

Many large technology companies attach great importance to corporate culture and decide whether to hire them based on whether they are in line with the company's values. If you're interviewing in a company like this, it's important that you find ways to understand the company's values and identify your own past experiences that fit into your company's culture and show it to the interviewer.

(5) Pair programming

A very interesting type of interview is to have you and another engineer pair programming in a set programming environment, which is very similar to the actual work scenario. You will be assigned a basic task that lists the list of requirements you must complete. After you complete each task, the interviewer will ask you to implement more functions until the specified time. In this process, you are free to use whatever resources you want to use, such as stack overflow or online documentation.

I have found that in such interviews, many candidates can rely primarily on their real-world development experience. Unlike whiteboard interviews, you need to write code that is grammatically correct in such interviews, so you should thoroughly understand your programming language and environment, because you certainly don't want to spend too much time searching for answers online or in a document during a programming interview.

In my previous job, when I was doing a task, I would write clean code and then optimize it when I thought it was done. This type of work is detrimental to this kind of interview.

(6) Find and fix bugs

As engineers, much of what we do is around finding and fixing bugs that we've collected from different sources. In this type of interview, you'll get a list of bugs that you need to find and fix, and in the process you'll need to identify other potentially problematic code.

I've only had one of these interviews, and I think it's really hard to be prepared for this kind of interview, especially for junior engineers who have all the skills they lack. Each coding environment has its own little quirks and nuances, and many of the bug fixes I've done come from the experience of the previous IDE (integrated development environment) and the frameworks I've accumulated over the years.

(7) Inspection of professional field knowledge

In most of the common languages we see today, programming is basically the same. If you know the object-oriented programming of a programming language, most of these skills can be transferred to another programming language. However, this kind of interview can not be in the language or the framework of the exchange between the two. The interviewer will examine your knowledge of your expertise in the areas of API, memory management, functionality, and limitations in a specific environment.

For interviews on such topics, practice is challenging. Similar to the discovery and repair of bug interviews mentioned above, I think the answer to this type of interview question comes mostly from past experience. Depending on the level of position you are applying for, the interviewer will evaluate your answer in a different standard. For example, if you are applying for an entry-level position and don't know why an API structure is specific, then the interviewer will make a concession in this respect and not be too demanding of you. However, if you apply for a senior position, the interviewer will be more demanding of you, then if you do not know the answer to this question, it will leave a very bad impression on the interviewer.

(8) Understanding of the operating system

Depending on the position or team you are applying for, you may have a specialized operating system interview. In this interview, you will be asked questions that the interviewer can use to evaluate your understanding of the computer operating system mechanism. To tell you the truth, this interview kind of caught me off guard. The operating system was something I had learned in college in the early years, but it slowly faded away.

(d) How you should prepare.

As I said above, the interview itself is actually a skill. Even if you are already a good programmer in your daily work, or if you have done well in your school, you will not be able to translate these skills into interview skills by 1:1 in the interview room. Persistence and repetition of the interview preparation and practice will largely determine the outcome of your interview.

(1) At least need to grasp this knowledge

If someone asks me what I think should be paid attention to, I suggest the following points:

First learn to write code on paper and whiteboard, and then put it in an IDE (integrated development environment) so that the syntax is highlighted, which should be your second nature.

Have a deep understanding of the data structures, including their strengths and weaknesses.

Fully understand the time and space complexity of the big O symbol, which will match your algorithms and sorting problems perfectly.

Master all the major sorting algorithms, because the complexity of time and space has the potential to destroy the best solution to the algorithm you want to solve.

(2) When to start

According to your own timetable, the sooner you start the better. Many of the companies I interviewed had a 12-month cooldown, and candidates who failed the interview had to wait 12 months before they could reapply for the position. Conversely, if you know you can't prepare for this interview in a year, you might as well start the interview process now, and probably feel the exact interview process, and then the real interview will not be so scared.

--------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------