Programming,

Website development

A lot of pain is poured out on the Internet about unsuccessful interviews. Some didn’t like the interviewers’ questions, others were offended by ridicule, others were judged based on their VKontakte page. The interviewers keep up with the applicants and swear about how bad the staffing situation is these days, and what stupid answers inexperienced programmers give to their tricky questions. technical issues.

Unfortunately, there are no universal rules for passing and conducting interviews, and cannot be, because employees are selected not only by their technical skills and personal qualities, but also by matching some (often implicit and very subjective) “profile”, which, according to interviewers, fits into their team or company. As for the guides from the series “how to pass interviews correctly,” they usually cause no less pain in the comments, because they are very subjective and are sure to touch someone’s pain points.

Over the course of my professional career, I've been on both sides of the fence, although I've probably had to do a little more technical interviews than pass them. But during this time, I have accumulated a number of “fads” that scare me away during a technical interview and immediately in my mind put an end to further conversation. This is what I wanted to talk about - from the perspective of the interviewer and the applicant. I would like to immediately make a reservation that the article reflects my personal subjective impressions and does not pretend to be a “guide to interviews.” On the other hand, this is not a momentary outburst of rage from a failed interview, but a long-weighted set of criteria that, albeit on a negative basis, allow me to weed out options, or not to scare away a potentially suitable applicant.

What irritates or stresses you out during interviews? Share in the comments.

Interview from the applicant's perspective

Every time a programmer looks for a job, he has to go through many technical interviews. He walks around offices or talks on Skype, solves problems or takes tests, answers tricky technical questions, trying to demonstrate himself with the best side. However, he himself also evaluates the people who interview and test him, thinking that tomorrow he will potentially have to work with these people. And there are plenty of ways for technical interviewers to scare candidates away from an interesting position. I will tell you about what has always scared me personally, and what I try to avoid as an interviewer.

1. “What other technical interview?”

The first and most important thing that has always alarmed me about a technical interview is its absence. It happens that the entire conversation with technical specialists - potentially future colleagues - is based on questions regarding professional experience: where he worked, what projects he worked on, what function he performed in them. Regarding technology or knowledge - questions at the level of “what color is the textbook.” Do you know what a Message Broker is? Great, we'll take you!

This approach to interviewing has always turned me sharply against a potential employer. They didn't ask me a single question to check that I really knew what I was doing. It looks as if the people interviewing me either don’t understand anything about the topic themselves and are looking for at least one person who understands, or are simply desperate and ready to take on anyone. In any case, I would hardly want to work in a team recruited in this way.

2. “Well, what were you doing there in that…”

It's surprising how often dismissive attitudes toward applicants occur during technical interviews. Yes, perhaps you are a stern and experienced programmer with a bunch of projects under your belt, you were torn away from extremely important work for the sake of some unnecessary interviews with people, most of whom, in your opinion, are completely incompetent. But do not forget that at this moment you are representing your company and your team, and a person will definitely make an assessment based on your behavior about the climate in the team and how they will treat him in this team. Be polite and respectful to the applicant, even if from the first five minutes you realized that he should not be allowed anywhere near your precious code.

3. “Your first name/last name/patronymic name is written incorrectly on your resume!”

This is not at all technical, but, nevertheless, a common problem even in technical interviews. Fortunately, I have a fairly simple and common name, and such problems have not happened to me. However, I know that there are a surprising number of people who firmly believe that certain names and even patronymics simply do not exist. They will convince you that the correct name is not “Danila”, but “Daniil”, or that there is no name “Alena”, but only “Elena”. They will offer to correct and write “correctly” in their documents. People with rare or unusual names, and believe me, it's incredibly annoying. So, there is one simple rule: there are no such names that do not exist. Correctly write as written in the passport. Show respect to the applicant and do not consider him so stupid that he is not able to copy from the passport into the resume given name. Even if you suspect a mistake, you can clarify this in a more tactful way.

4. “How many golf balls would it take to clean all the round windows on a school bus shrunk to the size of a nickel during the evacuation of San Francisco, using no more than 3 weighings?”

No article on interviews would be complete without mentioning manhole covers. You can consider this my personal quirk related to the inability to quickly and under pressure solve non-standard problems. But I am sure that brain teasers are absolutely useless during interviews. Or rather, it's great way recruit a full department of brain prodigies with the Brain Olympiad, who will exchange fresh brain teasers all day long instead of working. Real programmer in natural environment life, even when dealing with very cool and non-standard tasks, he still rarely codes under stress, and spends most of the day sitting and leisurely thinking in a relatively calm atmosphere about how he can beautifully cut the code into methods. He never uses his “brain muscles” to solve tricky problems in this process.

5. “Wrong. Further."

Of course, it is not the job of the interviewer to train people coming for an interview. However, if the applicant could not answer the question, but is still interested, then prompting or at least pointing him to the correct solution before moving on to the next question is a question professional ethics, a demonstration that if something happens, they will help him, teach him, and will not leave him alone with technical problems. Tell him at least a few words, what to google, what to read. After all, interest in the right decision tasks are in themselves positive quality a technical specialist, and you should not demotivate such a person by disparaging his mistakes or inaccuracies.

Interview from the interviewer's perspective

Every time a new vacancy opens, a leading specialist or department head has to conduct many technical interviews. People with different technical experience, training levels, and expectations come to interviews. To conduct interviews, you need to think through a conversation plan, draw up a list of questions, and then try to understand from the answers to these questions whether the person is suitable for the position or not. And sometimes applicants during interviews say such things that it becomes immediately clear - no, you cannot work together with this person. Here is a selection of key phrases from applicants that alarm me personally.

1. “Some of your questions are theoretical. I'm not strong in theory, I'm seasoned in practice! Let’s do a better test!”

The word “theoretical” is usually pronounced with a dismissive connotation, as if it were something bad. But that’s not even the problem. Do you think this phrase was preceded by the interviewer's request to prove Cauchy's theorem? Give precise definition third normal form? Not at all. I heard such exclamations in response to the following questions:

• How is comparison by == different from comparison by equals in Java?
• tell us how the hash map works.
• Explain in your own words what REST is.
• What are transactions and why are they needed?

Yes, from a certain point of view, any programming question is theoretical if it does not require you to write a line of code right here and now. But I am sure that a person with sufficiently extensive experience in a certain field should be able to explain the most basic things in his own words, or at least not pretend that ignorance of them is normal and natural.

2. “I didn’t expect the Spanish Inquisition here! It's just like taking an exam at the institute. Usually they just ask where he worked and what he did.”

You have come for a technical interview. In a technical interview, you will be asked technical questions to test your technical skills. Leave the testing methodology and choice of questions to the conscience of the interviewer - the questions may not always seem adequate to you, but the interviewer knows exactly what information he wants to get about you by analyzing your answers. Many questions are needed not to test your knowledge, but to force you to think and look at your train of thought. Remember also that not all questions require a perfectly accurate answer, and if you clearly answer at least half of what they asked you, this will already make a good impression.

3. “I don’t need to know that, I specialize in higher level tasks!”

Don't confuse specialization with ignorance of the basics of programming. From the developers mobile applications I've heard similar things about the TCP/IP stack protocols from front-end programmers - in response to questions about sorting and searching algorithms. “Why should I know this, everything is in the standard library, I work at a higher level.” In response to such statements, I long ago came up with a couple of small problems with sneakily hidden algorithms - in the hope of showing that a “naive” solution, issued from ignorance of algorithms, does not stand up to criticism, and to at least encourage self-education. Moreover, these are not some artificially constructed tasks, but things that occur in development every day. Any code is an algorithm. Understanding basic algorithms and data structures is important for any programmer, and Internet protocols are a base, without knowledge of which it is impossible to competently write anything that goes beyond the boundaries of one computer.

4. “And you yourself! / Show me your code! / But I went to your GitHub, and there’s this...”

The last thing an interviewer wants is to hire a person and then have to listen to him criticize his code base. Yes, she is most likely imperfect. Yes, technical debt is everywhere and everyone has it. In any code there is something to criticize. But if you really consider yourself so cool that you see obvious problems in the code of your potential employers, translate this into a constructive positive: I know how to improve, I have experience on this topic, I can be of benefit to you.

5. “You are wrong!”

Anything can happen, of course, but it is better to keep your opinion regarding whether the interviewer is wrong or doubts about his competence until the end of the interview. Then Google it and figure out which of you was right. A technical interview is not a place for discussion or self-assertion, and the questions here are primarily asked of you. The interviewer will not ask about something that he himself does not understand.

Conclusion

Do you know what the nicest thing I heard from applicants during interviews? “I didn’t really answer, did I? Can you give me a piece of paper? I’ll write down your questions and figure it out at home, even if you don’t hire me, at least I’ll know now.” Tears of pride well up in your eyes - it was not in vain that you spent an hour and a half of time on a person, he himself learned something from this interview. Even if now he is too weak for this position, perhaps this will encourage him to educate himself, and in a year or two he will come again, show his best side and get a job - as happened once in my own career.

There is a lot of material on the Internet dedicated to interviews with HR managers, but almost nothing is said about the intricacies of interviews with technical specialists. This article is devoted to what qualities and skills a candidate must have in order to successfully pass this stage and receive an offer in an IT company.

Dialogue from life:

Candidate: We must perform operation “A” until condition “B” is satisfied.
Me: Great plan. Let's implement it.

The candidate writes a for each loop. Although it's obvious. If a candidate passes this level, he will sooner or later become a good programmer. But 70% of applicants fail here.

Bogdan Gusev, service station

Let's correct this annoying misunderstanding.

while (bool offer == false)(

Rule 0

If you are interviewing for the role of a Java developer, you need to have a good knowledge of Java and related technologies

//No comments.

Rule 1

Prepare for the interview in advance

Find out from the recruiter in advance all possible details about the project.

Google search for questions that are commonly asked in interviews. Some of them will definitely come across.

Alexander Pitz, Project Manager

Rule 2

Don't lie on your resume

Trying to deceive by exaggerating your knowledge is a waste of your time and the company’s time. You must be able to answer questions about all technologies listed on your resume.

A resume filled with keywords, about which you do not have a proper understanding, ruins your chances of receiving an offer.

Rule 3

Align your values ​​with the company's values

Every company has its own values. One team values ​​dedication and focus on results, and as a result, does not disdain overtime work. The other is innovative at work, and is willing to learn and apply innovations every couple of months. The third is reliability and stability: proven technologies, dedicated people who will not leave the company if the cookies suddenly disappear.

There is an acceptable limit of discrepancy between values, if exceeded, the company will most likely decide not to make an offer, even if the candidate has the necessary experience and the necessary technical knowledge.

Rule 4

Develop communication skills

I want the applicant to have better communication skills high level than the basic one. In our age of complete agile, this quality comes to the fore among the necessary skills. The candidate should not have difficulty communicating with HR and technical specialists, as well as with customers.

Rule 5

Improve your English

Unlike uncritical failures in knowledge of any technologies, you will not be able to improve your language in a couple of months. It takes years here. Therefore, insufficient level of English in most cases is a sufficient reason for refusal.

A little motivation: the level of English and the salary of Kyiv Java and .NET middles and seniors with 3-5 years of experience corresponds.

Rule 6

Show your passion for your profession

According to Bogdan Gusev, the fact that you enjoy your work can be indicated by the presence of Open Source projects, participation in thematic conferences, and mastery of text editor or IDE features. And, of course, interest in details further work. Programmers who are indifferent to their work are not in high demand among employers.

Rule 7

Show intelligence and abstract thinking

The candidate must:
- be able to solve problems corresponding to his position;
- know the required programming language and frameworks;
- navigate the technologies of the project for which he is being interviewed.

If the position is poorly defined, then general erudition and intelligence are tested, as well as the ability to think structurally and find solutions.

It is very important to demonstrate the ability to use your knowledge. If you know approaches and methods for solving problems and know how to obtain missing information, then you will be able to cope with the tasks you receive.

Rule 8

Demonstrate a desire to gain new knowledge

Sometimes a candidate will say, “I have studied technology X and I only want to work with it. Why should I study technology Y if I know X?” The chances of such a candidate getting an offer are sharply reduced. Technologies are just tools. After some time, X will become irrelevant, and with it the specialist himself, who only knows it.

Maxim Kovtun, Solution Architect

Rule 9

Show results orientation

I rate:
- the ability to compromise with one’s “religious beliefs” (for example, if a release requires it, use a “hot fix” rather than approach the solution fundamentally);
- the ability to insist on one’s own when necessary;
- and even more important - the ability to maintain the right balance between the two points above.

Andrey Mudry, Project Manager

Rule 10

Don't say "I don't know"

Exception: if you have never worked with this technology and it is not listed on your resume. In this case, it is better to be honest and ask the interviewer to explain the correct answer to you.

If you don't understand what we're talking about, ask a clarifying question.

If the question is specific and you are not sure of the answer, then you should admit it and be sure to make assumptions based on your experience. Explain your thought process. If the question is open-ended, then there is no single correct answer.

The worst answer is silence or “I don’t know.” You must try to solve the problem, no matter how stupid your solution may look. Even the most naive answer is better than nothing. Two or three answer options are generally great. Pepper these answers with considerations about their applicability and additional questions to clarify the problem - and it will be great.

Alexey Kolupaev, service station

Rule 11

Don’t be shy to learn even during an interview.

It's impossible to know everything. I once worked on a project that required knowledge of a rather specific technology stack and cartography. Experience has shown that few programmers can convert the classic coordinate notation from WGS84 to decimal notation. In such cases, I think a good answer in an interview is the question: “Can I look into Google?”

Artem Polyukhovich, CTO

Rule 12

Think about what you say in response

You don't have to pretend to be mentally active for a minute, but try to think about the problem as broadly as possible. Moreover, during interviews there are often trick questions.

It's good if the candidate tries to "infer" the correct answer to the question. He does not guess, but uses his existing knowledge, as well as logic, intelligence, resourcefulness and the ability to quickly make decisions under pressure. This quality is very useful in a flexible approach to development, when the customer requires quick solution problems, sometimes even during an online conference.

Sergey Chirkov, Project Manager

Rule 13

Admit mistakes you've made

The ability to analyze and admit your mistakes indicates that you will be interested in both your own professional development and the result of a specific job.

Rule 14

Don't ruin your reputation

An opinion about you can be spoiled by a careless answer to the question “Why did you leave such and such a company?”, disorganization, being late for an interview without warning, refusal to decide test task.

Rule 15

Build a partnership with the interviewer

It seems to me that in the expression “working relationship” many people focus on “working”, but they should put more emphasis on “relationships”. In this sense, an interview is similar to a date: you both take a closer look at each other, figure out whether you will be good together. And when someone tries hard to seem better than they are, it can be irritating. Sometimes a candidate can be so captivating that it’s easy to turn a blind eye to even serious shortcomings.

Alexey Kolupaev, service station

Rule 16

Behave properly

“Correctly” means politely, respectfully. Arrogance, ingratiation or flattery towards the interviewer will only spoil the impression. Humor is also not always appropriate.

Several failed behavior patterns can be identified:

• Friend- moves the conversation to an informal level in order to avoid specific answers to specific questions.
• conqueror- takes the initiative into his own hands, speaks loudly and a lot, and does not allow questions to be asked.
• lazy- after an hour of interview, he shows that he is experiencing real torment - such a person is unlikely to be able to work intensively for more than 1 hour a day.
• architect- creates a large number of useless classes before outlining a solution plan. As a result, it itself cannot take advantage of its own “architecture”.
• theorist- the most dangerous type, ready to communicate on any topic, as long as he is not forced to show practical knowledge. Can easily describe a solution algorithm, but is not able to program it.

The latter is easily determined by the following dialogue:
Me: Bring your laptop to the interview
Candidate: Why?

After such a dialogue, it is immediately clear that the candidate believes that the main thing in being a programmer is talking about cool technologies in the kitchen. He doesn't know that programming on a familiar keyboard is much easier than on a foreign one. Consequently, he spends little time on it. I wonder how his work day is going?

Bogdan Gusev, service station

Rule 17

Be adequate :)

Adequacy is a fairly broad concept. First of all, it includes a reaction to difficult situations. What does a person do when faced with an incomprehensible piece of code or a complex algorithm? How will he behave with colleagues when he needs something from them (or needs them)? What does he do if a conflict of interest arises? What if he is given an impossible or difficult task?

Artem Polyukhovich, CTO

Rule 18

Be optimistic

Positive attitude - very useful quality. It is much more pleasant to work with a person who knows how to notice positive moments in life, in work, in everything.

Rule 19

Feel free

An interview is a discussion between two equal specialists. Thus, stiffness is more of a minus than a plus. It will prevent you from expressing yourself at the proper level.

But too much self-confidence is also a minus. A monologue for 20 minutes without stopping can serve as a reason for refusal.

Behave naturally, don't be shy. For example, if you find it easier to process information visually, don't be afraid to ask for paper and pen.

Rule 20

If you fail, learn from your mistakes

See the interview as an opportunity to learn something new and gain feedback. This will be beneficial even if you don't receive a job offer.

Alexander Kaganovsky, service station

Hello everyone, Javarashites! It just so happened that I recently had an interview and would like to tell you what questions I was asked assuming that I was applying for the Junior++ position. Those. Not a middle yet, but not a green junior either. So, the interview went according to this plan

1. JavaCore
2. Databases.
3. The tools you use.

JavaCore

First, I was asked to draw the hierarchy of interfaces for Collections (it was not difficult, there are only a few of them (Collection, List, Set, Queue, Map).

What is the difference between ArrayList and LinkedList (this is one of the most hackneyed questions and answers on the internet, just darkness).

We discussed the speed of query execution in them and what the difference is between the sheets.

Question about the Object class. What are his methods, what do they do?

Reflection. What the getClass() method does. Very interesting question, take it apart. Especially about how to get everything about a class, even if it contains private methods or variables.

They asked about multithreading. It’s weak, I think, to tell you how you understand what multithreading is. What is needed to start a new thread. Realistically, if you are level 20+, then these questions will seem funny to you.

What can you say about Stream. This is not about Java 8. It is about input and output streams. Like basic interfaces, what they are (character and byte). For understanding, no specifics.

• Exceptions. Here again we were asked to draw a hierarchy of exceptions, what types there are, which ones are checked and which ones are unchecked. What to do with Runtime exceptions. Name the most common NullPointerException.

The question is what should be done with checked exceptions (forward further or process - both are clear).

OOP

What is OOP in a nutshell?

What other programming paradigms are there? How are they different from OOP?

What are the basic principles of OOP (inheritance, polymorphism and encapsulation)? Tell us about each of them. So far everything is abstract, not tied to any language.

System design understanding task: there is a Horse and a Bird. We need to get Pegasus. principle "has a" and "is a"

REST

What is REST. Wikipedia talks about this very coolly. In fact, an article from Wikipedia is enough to get acquainted with.

HTTP. There are also general phrases here. His methods, what each of them is for.

HTTP status codes. What five parts should it be divided into? Tell us about the most famous ones (200,204,404,500,501). Why do they? They also asked about 401 and 403. But I didn’t know them. They said they were important.

Databases

Here I told you that I know MySQL. Told about three normal forms. I talked about Joins, what they are, and drew the intersection of areas in which different joins are used. I talked about how I understand a relational database. I also didn’t forget about MongoDB - this is a NoSQL database. After some time, I will write about that too.

Other tools

Here we went through my resume. It was written that I use Maven/Gradle for assembly, I use JIRA for tasks, git, Docker, Swagger. For Continuous Integration - Stash, Bamboo, Puppet. For testing JUnit, Mockito, JMeter. I might have forgotten something, so if you're interested - ask in the comments I'll try to answer. This was the first part of the interview. Now I’m waiting for the results and if yes, then there will be a second part. I will write about it as soon as possible. Anyone who liked the article and found it useful - put "+". Write in the comments. See also my other articles:

Siraj Rawal, developer, writer and vlogger, shares how to ace any technical interview in 5 steps.

I've gone through this process a dozen times in various IT companies in my memory. huge number both refusals and offers. And here are the lessons I learned from it. Interviewing takes work: don't believe those who say it should be easy. This is wrong. People talk only about their successes and never about their failures.

I have outlined several steps that will allow you to avoid many mistakes and successfully pass any technical interview.

Step 1. Preparation plan

Learn. Even before you have the bright idea of ​​trying to get a job somewhere, you should concentrate on upgrading your technical skills.

The hiring process for a developer position looks pretty much the same at many large companies. As a rule, it takes place in two stages. First, the recruiter communicates with the applicant by phone to understand how interested he is in their company. Upon successful completion of the first stage, it is followed by 1-2 technical conversations with specialists, during which he is asked difficult questions and problems that he must solve on the board. He must show his thought process in solving a problem, find a suitable solution, and then he will be hired.

The only way to learn this is practice. All my friends who work in cool companies do a lot of work. The point here is not to have extraordinary intelligence, but to work hard and thoughtfully.

The question arises: what exactly should you practice? You will not be tested on your knowledge of the syntax of any language. If you want, you can learn the basics of Ruby syntax overnight. But what the night is not enough for is the basics of fundamental computer science. But at the interview they will test your knowledge of data structures and algorithms.

Start by taking two courses:
introduction to data structures (My Code School)
Introduction to Algorithms (MIT Open Courseware)
Both of them are in open access and are ideal for getting basic knowledge for these sections.

After this, you can consolidate the acquired knowledge on HackerRank and HackerEarth. These resources contain a huge number of problems to hone your programming skills.

After solving a couple of dozen puzzles from both sites, read the books “Technical Interviews as They Are” and “Breaking the Technical Interview.” They'll walk you through many specific tasks from real interviews, from systems design problems to questions about time and complexity.

After completing all the above rituals, start rehearsing an interview with one of your friends. Ask him to ask you questions and answer them using only a marker and a white board and explaining your thoughts out loud. I recommend doing this for two to three months, two to three hours a day.

Step 2: Find companies that interest you

If the process of preparing for each interview takes two to three months, then, naturally, you would really not want to waste this precious time on companies that do not impress you.

Keeping track of companies' interview preparation and interview process can be quite stressful, but try to stay organized. Make a list of companies that interest you and note the stage of your relationship with each of them. Angel.co and Hacker News are good resources for this.

There is something supernatural about this. You will have to strain all your strength psychic abilities, to understand how to best apply your skills in your desired field and find companies that will allow you to do so.

Step 3. Create a portfolio

Large companies receive hundreds of resumes a day, so they simply need to weed out a lot of mediocrity that is not interesting to them. How to stand out from this gray mass? Make sure that all the words in your resume fit on one page and that it is concise but to the point. Illuminate it the most important work done by you.

It's a good idea to have several resumes: one for each specialty or for each company where you are trying to get a job. In your portfolio, separate personal projects, projects from hackathons, contributions to open source projects.

GitHub is a great place not only to store your code, but also as another portfolio that can serve you well.

Make your best web project your own resume website. Try to make it look stylish and professional so that it can impress a potential employer.

Step 4. Get an invitation to an interview

The easiest way is to apply for a company vacancy on a specialized website. But large companies receive many such responses every day, and it is very easy to get lost among them. Good option- send an e-mail to the company's recruiter, making it short and succinct. Include it brief overview about who you are and what you want to do, a link to an easily accessible and relevant project, and express a desire and willingness to learn and learn new things.

It's time to move on to...

Step 5. Pass the interview

Sometimes the interviewer may be more nervous than you are, and that's okay. Just smile, be polite, make it clear that you understand him and are willing to cooperate to achieve common goal.

When solving technical problems, don't be afraid to think out loud. Remember that this is exactly what they want from you: the correct answer is not as important as the correct train of your thoughts. When a job seeker comes up with the first solution, the recruiter often asks him to find better options. This is where your computer science knowledge comes into play.

And don't be shy to ask questions. The interviewer is there to help you. And despite the fact that his main goal is to evaluate your skills, it is also important for him to try to find a relationship with you. common language, collaborate with you and help you achieve a common goal. So if you come prepared, everything will be fine.

Conclusion

Preparing for an interview and passing it is a responsible and time-consuming process. Never, never, NEVER let rejection get you down. Passing an interview is also great experience, even if you weren't hired. Therefore, over time, you will achieve the highest skill and be able to successfully pass any technical interview. The main thing is to train, believe in yourself and stay motivated.

Interviews rank high on the list of most people's biggest fears, along with public speaking. Not only are you performing in front of someone, but you are also constantly being evaluated the entire time... brrrr!

Of course, we're far from trying to understand and overcome your psychological barriers, but it's definitely best to view interviews as a chance to show off all the cool things you've created and all the interesting new skills you've learned. Best interviews- these are enthusiastic conversations with a technical slant.

The first step before all this is preparation. You'll want to think about the possible questions (and the most common answers that highlight your brilliance) and research the hiring company. Your knowledge of the company will help you present yourself in a way that suits their needs, and will also allow you to ask smart questions about their products and technologies when the time comes. Once again, refer to Happy Bear's article for practical tips.

What is this whole process?

Just a little overview of the process the average goes through tech company when hiring developers:

1. Preliminary interview by phone (Phone Screen)
2. Technical interview
3. Test terms of reference
4. Follow-up interviews to ensure you are a good fit (Fit Interviews)
5. Job Offer
6. Discussion of offer terms (Offer Negotiation)
7. Offer Acceptance

Preliminary telephone interview

Congratulations! Your resume turned out to be not the most disastrous and you were invited for a telephone interview (note that sometimes you do a test task first). The real purpose of this step, which often involves a half-hour conversation with someone in HR (rather than the hiring decision maker), is to make sure you have a good chance of making it through the rest of the interview process. So think of it as a lighter version of the other steps.

You'll probably be asked about some of the technical stuff you put on your resume, but don't go too deep (although some employers do ask some pretty tricky questions), and you'll likely be asked some "softer" questions about why you chose this job. and what you did before. Telephone interviews can vary greatly from company to company. The main tactic here is not a tactic at all, just be honest, energetic and open. And don't be afraid to practice talking about yourself in front of the mirror.

A FINAL NOTE - This is not a one-size-fits-all method and many companies skip it in favor of diving straight into the depths of a technical interview, so you need to prepare just in case. The link below to Coding Horror is the most illustrative of this case.

• Achieve Phone Interview Excellence with Monster
• 7 Steps to Achieving Excellence in Telephone Interviewing

Technical interview

The technical interview is usually the scariest part of the selection process. This is where they will assess whether you have the required technical skills. This means that they will not only ask you in great detail about your work, but will also ask you to decide logic problems or write code right there or sketch out a diagram of some new components.

In fact, one of the purposes of such an interview is to take you to the very edge of your capabilities, just to see how you react to unfamiliar things. If you do an exercise too easy, they will move on to something much more difficult. There will always be places to stumble, especially for beginners. Your greatest asset is your honesty and curiosity.

When solving a problem, make sure you do it in a clear and logical way, explaining out loud why you are doing a particular step. Talk through all the obstacles you encountered and give examples of how you would solve it in " real world". Often the answer is to "Google" some specific function. Say so! They know you're not a Ruby expert, but they also need to know that you can come up with solutions to the problems you'll inevitably encounter on the job.

It's also completely normal if you use brute force - an inefficient method - to solve a coding problem. This is often the best starting point for getting a proper feel for the problem. Most likely you will be asked how the solution can be improved, but this is much better than trying to come up with the perfect solution and not having time to write anything in the end. Once again, your job is not to be a standout candidate, but to show that you are adaptable and stay sane when faced with challenges.

And if you don't know something, it's better to say it honestly and try to think it through with the interviewer. Believe me, they want you to succeed just as much as you do, because there is nothing worse for an interviewer than seeing someone silently trying to solve a problem, getting more and more stuck without asking for help and not letting anyone know what he was thinking.

You'll have to read about large quantities things that were not emphasized in previous courses, for example, data structures and algorithms, simply because they are very popular questions about them in interviews. They don't always reflect programming skills well, but it just so happens that you'll have to answer questions that fall into a more academic area of ​​computer knowledge.

Links

• Let's look at the interview for programmers: MUST READ MATERIAL who will be yours best friend. It takes a comprehensive look at all types of challenges you will face in an interview. It goes beyond what we've already covered in this course and touches on things that are good to know because you're likely to encounter them. Take the time to get to know as many as possible a large number material.
• Interviewing.io gives you the chance to practice anonymously and online technical interviews.
• How to get a perfect score in a technical interview
• How to Stand Out in Your Next Web Developer Job Interview
• Read 40 key computer science concepts explained in easy-to-understand language
• Google's Tech Skills Guide(for advanced)

Programming test tasks:

• 8 queens is a classic problem.
• Programming for Interviews: Know the Standard Libraries may be overkill for a beginner, but it never hurts if you take the time to do it.
• On Project Euler you will find more general and complex problems that need to be solved efficiently (they may require a lot of computation).
• Published on Coding Bat practical questions for Java and Python.

Algorithm training:

• Algorithms course from Udacity (not synchronized)
• Algorithms course from Coursera (partially synchronized)

Architecture:

Technical test task

Test homework may occur either before or after a personal interview, depending on the company. You will be given a task that will require a full day to complete at any time convenient for you. Examples of such an assignment might be creating a sample web application with tests or solving a complex algorithmic problem with writing code.

The evaluation will be based on the completeness of the solution and the quality of your code. If this occurs before the technical interview, then it is good method check your interest (up to half of applicants do not even return with a solution).

Final interview (“Fit”)

The last step before making a decision is usually getting to know the team and offices for a few hours. You may be tested technically, but the main goal is to make sure you will be a good colleague. If some other team member says that you won't work well, they most likely won't hire you. Advice? No need to be weird or awkward, even if you're at home :)

This is also an opportunity for you. If you've made it this far to get to this step, there's a good chance you're generally eligible. You need to consider whether you want to work for this company, so prepare a list of questions and get answers to them.

A little about wages

Not. Voice it out. Yours. Salaries. Expectations.

You will always be asked “how much would you like to receive?” Your Answer? “I would like to get paid at the average market rate” (unless you are so arrogant as to ask above the market price. Let's see how that works out for you). You won't gain anything by naming your desired salary level. If it turns out to be lower than what they wanted to offer you, they will simply lower this level. And if it is higher, then they will simply interrupt the whole process, deciding that you are too expensive for them.

Once you get an offer, you can check how it compares to the average market pay by asking a few people (hopefully you already know a few people to ask) or by going to Glassdoor (just remember you're a beginner, which means you will not receive an “average” salary). The most important thing is not to harm yourself when asked.