I will leave a note about the software engineer interview measures for companies such as GAFAM and FAANG, or similar trends (probably Indeed and PFN in Tokyo).
Foreign IT companies attach great importance to coding interviews when hiring software engineers. It's closer to a programming contest problem that is easier than business coding, and it seems that it is common sense for American students and engineers to take a few months of proactive measures when receiving an IT company. For the general interview process, see the book Book to Train Programming Ability to Fight in the World, but it is usually before you get an offer as a software engineer. , It will take about 3 to 5 sessions for a coding interview of about 45 to 60 minutes.
Over the last few years, a past coding interview site called leetcode.com has become widely used by candidates. Around 2018, I heard from Columbia University students that almost all computer science students have accounts and half are charged. At the time of the interview, it is normal to make the candidate promise not to leak the problem, but leetcode is morally gray because it collects the problem that seems to have actually been raised by a major company and has a billing business. .. Since the leaked problem becomes difficult to use, it seems that there is a cat-and-mouse game of "twisting the problem-> leaking", and the coding interview itself seems to have become a little difficult in recent years.
Despite these concerns, interview preparation using letcode is very useful for engineers who are not professional computer demons or genius programmers. Some of the skills required for an interview are difficult to train even if you do a let code indiscriminately, so I think that you can proceed with the interview in an advantageous way by preparing with that in mind.
Below, we will discuss what kind of preparation should be made by calculating back from the intention of the hiring side.
Coding interviews formally look like programming, but they are not a "test" that only competes for the correct answer to the question. Interviewers are trying to determine if a candidate can work with them as an engineer, primarily to see if they have the following abilities:
Ability to produce results by oneself ―― 1a. Understand complex logic and code accurately and fast enough ―― 1b. Know in detail the nature of the main algorithms and data structures and make the best choice at implementation ―― 1c. Appropriate software design
Ability to develop well within the organization ―― 2a. You can write code that is easy to read and maintain. ―― 2b. Two-way information exchange face-to-face can be performed accurately and at sufficient speed. ―― 2c. Take a positive and supportive attitude and consult with others to find better solutions
Based on this, we will describe specific measures.
Billing leetcode unlocks some additional features. In particular, the frequency of questions by industry as a whole and by company is high, and if you spend some time preparing for an interview, it is better to charge (each person makes a moral decision to pay for leetcode).
Classicized high-frequency problems tend to be avoided by the questioners, but it is best to solve them in order of frequency because there is a good chance that similar problems will occur and many of them are worth learning with good questions. If the receiving company is decided, it is better to proceed with both the frequency order of the company and the overall frequency order (both overlap to some extent). If time permits, it seems better to ask about 200 questions when receiving a top company.
One interview is about 45 to 60 minutes, and two questions (easy or medium) + (medium or hard) are standard. Since we will have a discussion after solving the problem, it seems that the time that can be used to actually solve the problem is 15 to 20 minutes for medium and about 30 minutes for hard. The speed of solving problems is important, so try to get used to writing algorithm code quickly.
Some hard problems are quite difficult for ordinary people to solve at first sight (https://leetcode.com/problems/cat-and-mouse/). The idea depends on the interviewer, but when an extremely difficult problem arises, it seems that he is trying to see the ability to discuss on the premise of hints (2b, 2c) rather than the sharpness of the head (1a) that solves with no hints. So when practicing, you don't have to think about unsolvable problems for a long time, and if you can't solve them in an hour at the longest, you should look at the explanations and other people's codes.
Even if you can solve it, you should always look at the explanation and the code of others. In the interview, after solving the problem, the amount of spatial complexity and the amount of time complexity are asked, and the trade-off with possible alternative solutions is discussed (1b), so it is valuable to touch on multiple solutions. Other people's code is often helpful for compact and good writing.
Unlike the online judge function of letcode, you cannot execute code in an interview, so once you write the code, make a habit of executing the test case by hand while taking notes of the value of the variable and debugging without using a computer. When I notice the edge case myself, the impression at the interview is very good.
Many interviewers say that "fine grammar doesn't matter," but it's better to be able to write accurate code without stagnation. Since the interviewer is also a human being, it can be unknowingly influenced by impressions other than what he intends to evaluate. First of all, from easy, practice to become Accepted in one shot after writing the code. Therefore, it is best to remember the grammar and algorithm-related standard library of the language you use as accurately as possible (see below).
Since you have to write easy-to-read code in the interview (2a), solve the problem while being aware that the common logic is usually difficult to function and the nesting such as for and if is not too deep.
In order to keep the solution in mind, it is better to solve the unsolved problem repeatedly at intervals of 1-3 months. I think it depends on the person, but even if you concentrate on it for 2-3 months (I), your skill will not improve suddenly, so it is recommended to practice little by little over a long period of time.
Python is recommended as the language used for coding interviews. It is advantageous because the amount of typing is small, frequently used algorithms are almost complete in the standard library, and interviewers can often read them. In fact, the vast majority of candidates use Python. Any other language you are familiar with is fine, but languages with weak algorithmic standard libraries and languages with a large amount of types (C ++ / Java) are a little disadvantageous.
Familiarize yourself with the grammar and algorithmic standard library of your language so that you can write accurate and idiomatic code. In Python, it's best to remember defaultdict, OrderedDict, Counter, deque, bisect, heap, map / reduce, comprehension notation, lambda expression (useful for writing sort keys), with notation, etc. .. Keep in mind that reading and writing files, concurrency (threading and locking), and random number generation, which are rarely written on the interface with leetcode, may be suddenly asked during the interview. If you can afford it, you can write the code concisely by remembering itertools accumulate, chain, product, permutations, combinations, etc.
Learn the basic algorithms and their computational complexity. The first volume of the textbook Algorithm Design Manual is recommended (the second volume is unnecessary because it is an encyclopedia of advanced algorithms).
A basic algorithm that you can implement from scratch and explain the amount of computation:
--Find, add, delete operations on unsorted arrays, sorted arrays, unidirectional / bidirectional linked lists, hash tables --Find and add operations on unbalanced binary search trees (path because delete is complicated) --Heap push, peek, pop (bubble up, bubble down) --Stack and queue --Notation for rewriting recursive function calls using an explicit stack --Insert sort, bubble sort, quick sort, merge sort (to be able to answer why quick sort / merge sort is O (NlogN) time) -(Addition) quickselect: Find the median (or kth largest element) of unsorted columns in linear time --Naive string search --Naive trie --Binary search --DFS / BFS of graph --Dijkstra's algorithm, prim's algorithm (complexity order changes when using priority queue) --Dynamic programming (use the editing distance of a character string as an example)
Recursive algorithms such as binary search, quicksort, and DFS / BFS will make mistakes as soon as you write them, resulting in an infinite loop, so practice repeatedly and get used to them. Whether recursion can be written correctly is important as a checkpoint for coding skills.
An algorithm that doesn't have to be implemented right away, but should be able to outline and answer the complexity:
--Hash table collision countermeasures (open address vs chain) --Implementation of a self-balancing binary search tree -timsort: When using Python, you can concatenate two sorted arrays and sort () to sort by O (N) time. --Heap initialization (to be able to answer why O (N) time) --Kruskal's algorithm (union-find), Floyd-Warshall, Bellman-Ford
At major companies, one frame usually has a system design interview. The higher the job level, the larger the system and abstract problem setting, and the ability to discover problems and design is required.
System design interviews are not as systematic as coding interviews, and it is more difficult to take proactive measures because it is subjective that the interviewer decides what is good or bad. It is advisable to simulate in advance the problems that can be expected from your work history and the position you are applying for. This material is paid in the middle but very useful: https://www.educative.io/courses/grokking-the-system-design-interview
If you are not from the so-called computer science system, it is best to have as much education as you can. It's bad if you don't know the basics at all, but there are many engineers who are not from CS, so you don't have to give up.
If you want to appeal the developmental content, it is better to honestly say that you do not know if you do not know it because it may be counterproductive if you talk with a baking blade (2b / 2c).
Mandatory
--Minimum knowledge of computer systems such as TCP / IP (If you are not confident, you can use the book "Why the program works". The book Minna no Computer Science ”seems to be a good way to check for lack of basic knowledge.)
nice to have
--Computer architecture
Generally, the required level is not high. Basic communication is enough, but if you don't understand what you're saying at all, you're more likely to fall.
If you watch your favorite content with English subtitles on netflix for about 200 hours, you will be able to talk about the atmosphere.
Check the description environment at the time of the interview in advance as much as possible. If a whiteboard or editor, or a machine for typing is rented for an on-site interview, is the keyboard layout familiar?
If your production is whiteboard coding, be sure to practice writing code on the whiteboard. Even if you can use an editor, practice without the automatic indentation function in letcode.
Note that if you start writing code silently for a problem, even if the solution is correct, you will lose a lot of points. Keep in mind that the reason people interview rather than online judges is broad communication (2a, 2b, 2c).
First ask about the time frame and how many questions you intend to ask, and manage the time yourself as much as possible.
Problems are often deliberately ambiguous, so when you hear a problem, ask a few questions to check the specifications. Frequently asked questions such as input / output formats, data size assumptions, value range assumptions, edge cases (empty containers, division by zero, self-looping graphs, etc.), and the possibility of multiple solutions. In leetcode, all the incidental conditions are written in the question sentence, but be aware that you are expected to ask yourself in the actual interview. Even if you ignore the possibility of numerical overflow in the end and code it, it is good to mention it once.
When thinking about an approach, say your thoughts aloud as much as possible. If the interview is in English and the candidate is not familiar with English, it will be quite difficult, but if it is strict, practice a little in advance. Use as much as possible in an environment where a whiteboard can be used. The interview is not an English test, so any means can be used as long as you can communicate. For a telephone interview in a video conference, it is a good idea to have a blank sheet of paper and a thick pen and write it on a large piece of paper for explanation.
If you get stuck in your thoughts, tell them how you got stuck and talk to the interviewer. Especially when the problem is difficult, it is highly likely that it is required to find a solution while consulting rather than solving it with no hint. It's a bad impression to throw the interviewer like "give me a hint", but the counseling style such as "what do you think about xx?" And specific questions can be rather positive. If you have knowledge that you can't remember, it's better to ask a quick question than to shut up.
Briefly explain (preferably several) possible approaches before you start writing code, and explain the trade-offs between computational complexity and implementation complexity. Check with your interviewer before you start writing about the approach you have chosen.
Note that the code is easy to read. It's okay to assume features that aren't in the standard library, but be sure to communicate their specifications.
After writing, manually test using an example. At this time, hints may be obtained from the interviewer's reaction. Even if the interviewer is aware of the bug, the interviewer does not want to point it out directly, as it eliminates the possibility that the candidate will notice and fix it. There may be a mistake in the code when there is a subtle silence or when you are prompted to "test" or "explain the behavior".
Large companies may ask questions about leadership and interpersonal relationships, citing past experiences and hypothetical situations. Even if it gets a very good technical evaluation, it should be noted that it basically falls when it is regarded as a red flag in terms of behavior.
The hiring side basically thinks, "I want someone who can make correct value judgments, move voluntarily, and take active leadership, but I don't want people who disturb teamwork or discourage others." There is. Depending on the corporate culture, people who are aggressive to their surroundings are strongly wary of foreign capital (brilliant jerks). Therefore, in the interview, balance the leadership appeal and the cooperative appeal.
When asked about your motives for changing jobs, you should avoid saying bad things about your previous job and give positive reasons. It is dangerous to be regarded as a person who blames the surroundings for the cause of failure. Please note that this area is the same as Japanese companies even with foreign capital.
In the interview, elements of luck such as compatibility with the interviewer (interview anti-loop) are inevitable. .. There is always a way to fall that seems unreasonable, and it is very painful to prepare a lot and fall, but failing is not necessarily due to lack of ability.
If you do not have an interview experience with a company of the same type, it is best to avoid receiving your first choice first and gain experience by receiving as many companies as possible.