Geekly Articles each Day
📜 ⬆️ ⬇️

Interview without a hitch: as a programmer to successfully pass an interview

The post was prepared specifically for the corporate blog Wirex - a company offering a convenient mobile financial application for managing personal accounts. Initially, the article was conceived as a preparatory material that the author sends to his candidates, but in the end the latter decided to publish it in open source, and we, finding the topic interesting, made a translation for you, dear readers.

The fact that you are a good programmer plays a strikingly small role during the interview. In order for your work to be productive, you need to be able to solve enormous, problem-prone problems for weeks and months. Each question on the interview, on the contrary, lasts less than one hour. In order to show yourself well in an interview, you need to know how to quickly solve small problems under pressure, while clearly stating your thoughts. This is a completely different skill (at the same time, I don’t say that the ability to easily solve problems during an interview has no connection with programming skills. It’s just that this relationship is expressed much weaker than many companies believe, and it is other factors that differ from specialized skills explains such an impressive discrepancy).

Moreover, interviewers often do this unprofessionally and somewhat absently (they themselves would prefer to do programming instead of an interview), and therefore ask questions that are not related to the actual workflow. As a result, in the course of the interview, candidates are confronted with prejudice, lack of standardization and issues in comparison with the sample.

As a manager of a recruiting company, I understand this well. We conduct interviews with engineers without studying their resumes, and following an accelerated procedure, we send them directly to further interviews with other companies of the Y Combinator business incubator. Over the past nine months, we interviewed 1000 programmers. We pay special attention to practical programming, and allow candidates to choose one of the seven methods of assessment. This means that we work with many (very talented) programmers who have not completed even an elementary computer science training program. Many of these people do not perform well at interviews. They deal with enormous problems every day, but the 45-minute algorithm causes them difficulties.

The good news is that interviewing is one skill that can be learned. We successfully train candidates so that they can have an interview with the best results. In fact, the quality attributed to us regarding the preparation of candidates undergoing interviews at YC is not pure talent, but rather diligence.
')
By and large, I am convinced that good programmers are not obliged to acquire special skills that help to successfully pass the interview. But nothing can be done about the status quo. In the meantime, if you want to make the best impression on your job interview, this post will tell you how, in our opinion, to achieve this most effectively.

1. Show enthusiasm


Enthusiasm has a huge impact on job interview results. About 50% of our candidates who did not pass further interviews in companies failed them not for technical reasons. Companies usually explain this by saying that a person “does not fit into the company's culture.” However, in nine out of ten cases “to fit into culture” is to show enthusiasm in what the company does. Companies hire people who have a keen interest in their mission. For many, this is just as important as technical knowledge. And that makes sense. Motivated employees will feel happier and work harder.

The problem is that it can be played. Some candidates manage to convince every company in which they are interviewed that they have only dreamed about this job all their lives, while others (sincerely motivated and interested in work) cannot convey their true aspirations. We meet again and again with this. The solution here is one for everyone - learn how to show your enthusiasm. This does not mean that you are allowed to cheat. An interview is like a first date. No one wants to hear on the first date that he is only one of many options, even though it usually is. So here, most programmers just want to have a good job with a decent salary. But starting with this interview should not be. It is best to prepare notes before the interview about what you like in the company and to mention this when the interviewer asks if you have any questions. A good source of ideas can be reading recent posts in the company's blog and press releases, then you can mention the materials that you found most interesting.

This idea seems rather superficial. I think that by reading this, you yourself agree. But (and anyone who has ever interviewed will tell you the same thing) the percentage of candidates who do this is amazingly small. If you carefully prepare notes on why you find the company interesting, it will really increase the likelihood of your passing. You can even refer to your notes during the interview - this will show that you are preparing.

2. Study the terms commonly used in interviews.


A huge percentage of questions asked at the interview concerns the data structure and algorithms. It's true. We collect information from candidates about the questions asked at interviews at YC companies, and more than 70% of the questions are about algorithms. You do not need to be an expert, but knowing the list of algorithms and data structures below will help you get a job at most companies.


Depending on your education and previous work, this list may be either simple or completely intimidating. These concepts are much more common at interviews than in reality in web programming. If you are self-taught or have graduated from an educational institution a long time ago and these concepts are unfamiliar to you, then you should study them for a successful interview. Even if all this is not new to you, it still does not hurt to refresh knowledge. An astoundingly large percentage of questions at the interview is reduced to searching widths or using a hash table to count unique items. You must be able to write a BFS algorithm and understand how hash tables are involved.

Learning all this is not as difficult as many people with whom we have spoken. Algorithms are usually explained in scientific language, and this can be confusing. But in essence, nothing from this list is more complicated than the architecture of a modern web application. If you can (well) build a web application, then you can learn this too. For my part, I can recommend the book by Steven Skiena entitled “Algorithms. Development Guide "(The Algorithm Design Manual). This material is beautifully presented in Chapters 3–5 - simple and accessible. Yes, the book uses C and mathematical syntax, but it perfectly covers the topic. On Coursera you can also find some good courses on algorithms. In this course, in particular, attention is paid to the concepts, knowledge of which is important during the interview.

The study of algorithms and data structures helps not only because the material is necessary for success at the interview, but also because the approach to the problems taken in the course of the algorithm is the same approach that works best in the interview. Learning algorithms will help you get the right mindset for the interview.

3. Use the help of your interviewer.


Interviewers help candidates. They give hints, react to ideas and usually guide the interview process. But they do not help all candidates equally. Some programmers are able to get significant help in such a way that the person who conducts the interview will not reproach them. Others are condemned for any hints they receive. Believe me, you want to be helped.

It depends on how communication develops. If your interviewer likes your approach and you find a common language with him, he will be happy to help you. You can achieve this by developing a specific interview algorithm. I recommend the following steps:


After you have been asked a question, start by defining what you are being asked about. This is the moment when you have to be pedantic. Clarify all the ambiguities that you find. Ask about borderline cases. Give specific examples to start solving the problem and make sure that you understand what the final result is expected of you. Ask questions, even if you are practically confident in the answers. This is useful because it gives you the opportunity to find out borderline cases and get all the data needed to solve the problem (the candidate’s ability to work with borderline cases is one of the key aspects that interviewers take into account for the overall assessment of the interview). In addition, it gives you time to collect your thoughts before you begin to solve a problem.

Next, you need to talk about the simplest solutions to problems that only come to your mind. You should speak and not take up writing code immediately, so when verbally explaining your ideas, you can quickly answer the question and move on to the next one, and this will involve the interviewer himself, who in turn can help by guiding you. If you go straight to writing code, you will lose this opportunity.

Candidates often skip the first step, believing that the simplest solution to a problem is either too obvious or wrong. It is not right. Make sure that you always find solutions to your problems (even if you need to use exponential time or the NSA supercomputer). After you have described such a simple solution, ask the interviewer if he wants to implement it or if you should come up with a more expedient solution. As a rule, you will be asked about the latter.

As for a more expedient decision, state your thoughts as for the first time. Again, talk instead of writing code, and throw ideas at the interviewer. It is hoped that the question will be similar to anything you have already seen, and you will know the answer to it. If not, then you should think about the most similar problems in this case you faced, and on the basis of this build your answers. Most of the questions at the interview are related to slightly veiled applications of the classic CS algorithms. Often the interviewer will lead you to this algorithm, but only if you start the process yourself.

Finally, after both you and the interviewee agree that you have a good solution, you should start writing the code. Depending on the company, you will write the code either on the computer or on the blackboard. But since you already have a solution, the task before you should not look like something intricate. For extra points, ask your interviewer if he wants you to write tests.

4. Talk about solutions


An interview for a programmer’s position usually consists of questions directly related to programming, and it was about them that I mentioned earlier in this article. At the same time, you may encounter questions about creating a specific system. Companies seem to be inclined to “torture” in this way more experienced candidates. In this case, the potential employee is asked how they would develop one or another complex system for applying to real data. As examples, use the development of Google Maps, social networks, or, for example, the creation of API for the bank.

The first observation: the answer to questions related to the development of such a system requires specific knowledge. No one will require you to create Google Maps (it took a lot of time from many people). At the same time, the interviewer expects from the candidate some understanding of the basic principles for developing such a system. Do not worry, usually all such questions are related to the backend, so you can make significant progress if you understand the relevant information well. Here is an incomplete list of what is recommended to be studied before the interview:


You need to not only learn these terms, but also understand how they interact with each other, forming real systems. The best way to learn these concepts is to read about how other programmers have implemented these tools. Blog High Scalability is the best for such reading. This resource publishes detailed materials about a specific backend architecture in a particular existing company. This way you can find out how each solution from the list above is used in real systems.

As soon as you are finished with reading, the answers to the questions on the creation of such systems will turn into the sequential execution of a given algorithm for you. Start from the highest level and then gradually go down. At each level, ask the interviewer about the requirements (do you need to present a simple initial stage of development, or should you tell how the full system will look like?) And talk about several options (for example, you can use ideas drawn from online materials). Discussion of various options and trade-offs in the course of problem solving is the key to success. For the interviewer, it’s actually not so important whether you can build a good system. He is more interested in how well you can reason about finding the optimal solution by analyzing the advantages and disadvantages of the proposed options. Practice such talk.

5. Emphasize your work.


The third type of questions you may encounter at the interview relate to your professional experience. Here the interviewer usually asks the candidate to tell about completed projects. The mistake of many programmers is that they talk exclusively about the technical side of a project. So, most experts talk about the successful implementation of a neural network classifier or the implementation of a bot to check grammar on Twitter. This is not the best choice, because it is very difficult for the interviewer to judge the scope of the project. Many candidates talk about various side projects, exaggerating their significance, and the interviewer has no way to check if he hears the truth or beautiful lies.

In this case, the optimal solution is to choose a project that showed specific results and emphasize them. Here you often have to sacrifice a more interesting (technical point of view) project, but believe me, it's worth it. Think (in advance) about the project that showed the most "tangible" results in the real world. If you created a game for iOS, and it scored 50 thousand downloads, this is the figure that should be voiced. Or, for example, you, passing an internship in a company, wrote an interface for access to the "admin", which was later decided to be used for the work of all administrators. The fact of using the result of your activity is an excellent reason to tell about your achievement. In addition, choosing a more “technical” project when answering a question about your past achievements sends the company information that you are focused on the work itself. Programmers who are more interested in the “technical” side of each project, rather than the results achieved, are usually eliminated at the initial stage of recruitment (it is believed that sometimes such specialists are not productive enough).

6. Use a dynamic programming language, but be sure to mention C


I recommend that you use dynamic languages ​​such as Python, Ruby, or JavaScript for your interviews. Of course, you should use any language that you know best. , C, C ++ Java, - , «» . , Java C ++. , — . , . , , , . . ( ), , .

, , , . , . , , . - - , . - , C, C++, Go Rust, .

Java, C# PHP - . , . , , , , . , . , .

7. ,


, . , — , , . — . , . , ( ) , . , . ( Cracking the Coding Interview, « . Google, Microsoft IT-») . , 20 . ( , , ). . , , . . , . ( ).

( ) . — , , . ( ) , . . , . , , , , .

8.


. , , 30% , , ( , ). I do not like it. , , , , . , .

9.


- , , — . , . . , — , .

: . , , , . .

Conclusion


. — , . - , . , , , . - , . , , . . .

. , , , , . , , . , , .

Wirex. — Geektimes ! Wirex, .

Source: https://habr.com/ru/post/392027/

More articles:


All Articles