Подготовка к собеседованию в компании большой пятерки

    According to my impressions, a lot of people are interested in the topic of preparation for interviews with top technical companies, so I decided instead of personal answers to write one article that I will refer to in the future. Anyone who is interested in the process of the interview itself, the things you need to pay attention to, how to prepare and what to prepare for - welcome under cat.

    What is in this article

    • Training program
    • List of resources and articles
    • Job Interview Tips

    Before starting my training, I decided to work out a system for which I will prepare, as well as a list of resources that I will use in the preparation process.

    The first step was to determine what would be required for the interview, and for this, respectively, it is necessary to be well aware of what questions are encountered at the interviews. After a fairly quick pass through the search results of Google, I came across this book , which is a fairly complete collection of useful tips and examples of assignments on the subject of interviewing.

    At this stage it is worth mentioning that the code in the book is mainly written in Java / C ++, which makes it fairly well readable. Accordingly, for a more comfortable interview, I recommend solving all tasks in the language that you plan to use during the interview.

    After reading this book, I was able to determine the list of major topics for preparation.

    My list looked something like this:

    • Big o
    • Puzzles
    • Application architecture
    • Algorithms and data structures


    Actually, there is nothing special to talk about Big-O, you just need to know and understand the difference in the computational complexity of different algorithms, understand how to determine runtime and memory consumption of algorithms, know the basic steps to optimize algorithms, etc.
    There are countless articles and books about Big-O , in almost any input course about algorithms there are lectures devoted to this topic. Habré also has a series of articles devoted to this topic habr.com/post/196560


    Disclaimer - I personally did not come across puzzles at the interview, but I heard that they can come across.

    The way I saw puzzles in terms of preparation is actually the same algorithms, only without reference to a specific data structure or algorithmic paradigm. Because of this, it is quite difficult to systematize puzzle training. The best solution I could come to is to simply “fill my hand”, solve 40-60 puzzles and to some extent understand how to approach solving puzzles. Over time, the brain begins to understand what to pay attention to, and what is just the formulation of the task: for example, all the numbers specified in the puzzle are usually not just. This is not "just 2 ropes" and not just "burned in 25 minutes." As a rule, puzzles do not contain useless quantitative information.

    Application architecture

    Understanding the construction of application architecture comes with experience put on knowledge. It is rather difficult to become a good architect only about architecture and it is rather inefficient to study architecture purely by trial and error. For these reasons, it is quite difficult to “prepare” for the architectural part of the interview. To some extent, the preparation for this part is your entire career. But it would still be a good idea to refresh some aspects. For example: representation architecture. Even those who are good at UML at a critical time can simply forget some of the details of the presentation or the specific representations of the links. Another example would be popular design patterns. Despite the fact that they are quite often used, as a rule, they are not used all at once and not on demand to provide knowledge about them here and now.

    Algorithms and data structures

    One of the most important and most problematic moments in the interview. A certain emphasis is placed on the solution of these tasks, and the ability to solve such problems quickly and efficiently is quite important.
    To prepare, I compiled a list of data structures and algorithms that occur most often and it turned out something like:

    • Arrays
    • Strings
    • Binary tree
    • Binary Search Tree (BST)
    • Graphs
    • Heaps
    • Linked List
    • Matrix
    • Stack
    • Queue
    • Trie
    • Backtracking
    • Divide & Conquer
    • Dynamic programming
    • Sorting
    • Greedy

    In each of the sections there are several techniques that just need to master. A classic example of such a technique can be a “slow” and “fast” slider on a Linked List. Without knowing or understanding this concept, it is almost impossible to effectively solve very many tasks on linked lists. Or BFS / DFS graph search algorithms. As a rule, many interview tasks will be either modifications of known concepts or a combination of several. Therefore, it is very critical to learn how to solve and recognize the basic tasks in each data structure / algorithm.

    Personally, I watched a few lectures from Stanford University, and after that I wrote out about 5-10 tasks from each category and just filled my hand in this way. It takes a lot of time and effort, but as a result it is worth it.

    Here are a few resources that I used to prepare and search for tasks:

    https://www.quora.com - just a list of ~ 500 tasks for different topics, along with solutions in C ++. Quite convenient, sometimes there are several solutions, where one is more optimal than the other.

    https://www.hackerrank.com is a convenient resource with headings and topics and with built-in compiler for 20+ languages. Helps to quickly and efficiently tamper.

    https://www.glassdoor.com - contains directly questions from an interview and sometimes answers from the community.

    For me, these two were enough, but if you are not, then these 3 will give a good idea of ​​where to look further.

    Remember that it is very important to try to come to the answer and decision yourself before watching the prompts. In this way, you actually force yourself to think and seek a solution, i.e. directly simulate the atmosphere of the interview.

    Do not sin to use only a computer for solving problems. Try to train on the board or paper, because Many companies interview this way.

    It may seem to you that this is the same thing, but in practice, the practice on paper will open up many surprises, starting with the fact that you first need to come up with an entire solution before writing (delete and backspace are not there, deleting and moving lines is very expensive), and ending with that space on a sheet / board needs to be properly saved, because it is limited.

    What you pay attention to during the interview is confidence and pace with which you solve problems, thinking through all possible input data options, handling errors and various conditions. Therefore, to write just a “working” solution is not enough.

    Good advice will also be writing compiled code. Yes, undoubtedly, the main thing is the ability to solve the problem and its variations, and no one will pay too much attention to the 1 missing comma, but this should not be a rule. You write code and real solutions, not pseudocode and sketches.

    During the interview itself - try not to close your creativity, many decisions require an approach from a non-standard perspective. If you are closed - do not hesitate to ask for help - it will not greatly improve your chances, but you shouldn't stand silently for 45 minutes either.

    Perhaps this article will not be a complete and comprehensive guide, but it will allow you to understand in which direction to go.

    Good luck to everyone in the preparation.

    Also popular now: