Getting Rid of Fear of First Employment

Frame from the movie "Harry Potter and the Prisoner of Azkaban"

The problem of this world is that educated people are full of doubts, and idiots are full of confidence

Charles Bukowski

Recently, I held another one-to-one programming lesson. Unlike ordinary classes, the topic was not the construction of the language and not the problem in solving the problem. The student shared his concerns about future employment. The student himself was pretty smart. One of those who come to the courses goes through the entire program faster than anyone and with original solutions, but always sincerely underestimates himself. In my opinion, such doubts arise only from a lack of information. I tried to fill this gap impromptu during the lesson.

The questions were something like this:

• Every year, many students graduate from universities and they all go to look for work. This is a lot of people. They will probably take the best, but I won’t get a place.
• What if I screw up and get fired right away?
• What if in the process of work they realize that I'm stupid and kicked out?

This student was not the first person to whom I answered similar questions. Many people have them, and usually have to talk without preparation. This time I decided to write my monologue in a notebook. I thought that it would turn out a couple of paragraphs, but I typed into an entire article.

The article describes the view from my point of view and based on my experience. However, our world is very diverse and amazing things happen in it. If you disagree with something or your experience is somehow different, then please write a comment.

The article was written from developer to developer. However, if you plan to do testing, administration, or anything else in IT, then some of the tips will be useful to you too.

They won’t hire at all

When you imagine that hundreds of students graduate from many universities every year, it becomes uncomfortable. How to compete with such a huge crowd?

Unfortunately, not all graduates have sufficient technical training. Try to ask some familiar university student: how do people in his group get admission to exams in disciplines like the “database” or “the basics of algorithmization and programming”? In a group of 30 people at best there are 3-5 "advanced" guys who really did everything themselves. The rest simply write off from them, bison the answers to questions and pass.

That was when I studied myself. However, my experience could be unrepresentative. Therefore, I asked this question to several different students. The answer was about the same. The respondents were from different universities and colleges. I will leave discussions about the reasons beyond the scope of this article. I am not enough for a full-fledged study, so I will draw a conclusion from the available facts.

Among hundreds of graduates, only a couple dozen are of interest to employers

Few graduates can make a real competition for a capable student with good preparation. However, even if you studied in good faith, then after the first interview you will most likely not be hired. After the second, probably, too. Everything can work out well, but it’s better not to tune into an assault, but to siege. A failed attempt to get settled is just an excuse to work on the bugs and try again. I will not talk about preparation for interviews. A lot has already been written on this topic on the Internet. I can only say that there are nuances in passing interviews, for which it is unlikely that time is allocated to explain your training program. Look for this information yourself, it can reduce the number of attempts.

Madness is the exact repetition of the same action. Time after time, hoping for a change

Albert Einstein

To ensure that the interview does not turn into madness, after each new attempt, you need to become better. Remember or write down the questions that you were asked during the interview. Upon returning home, browse through this list and test yourself using the Internet. So you will understand where you were mistaken, where - the interviewer. This also happens. Repeat or study topics in which you answered poorly and try again.

In addition, there is a pronounced seasonality of the labor market. Competent companies plan hiring based on dates of graduation from educational institutions. In the spring of vacancies for beginners more than the rest of the time. However, competition at this time is higher.

Dumb - get fired

When a person is hired without experience, there are corresponding expectations for him.

From a newcomer to work expect:

• Knowledge of the general technical base
• Studying the features of the subject area of ​​the company
• Mastering the tools and practices used

Some organizations provide beginners with training courses on technologies, tools, and local practices. For example, the rules of good form when using corporate mail, the procedure for changing documents on a wiki, local features of working with VCS and a bug tracker.

There are still technical introductory courses, but their usefulness is dubious. If it came to employment, then the employers made sure that you have some sufficient level of knowledge. It is best to simply take such courses in good faith, as a small formality. Maybe they really will be something useful.

When you get to work, remember that the beginner will not be entrusted with solving the urgent, complex and at the same time important task. Most likely there will be only one of these properties. Or simple, but urgent: correct the layout, send someone a file, reproduce the problem. Or difficult, but without any hope of completion - in order for the beginner to collect more rake. Or important, but experimental. For example, a project that everyone has long wanted, but cannot allocate time for implementation.

Tasks for the development of tools will be "complex" and artificial. Most likely it will be a simplified version of the main system. In such tasks, the same technology stack and the same domain terms are used as in the entire project. In this case, the result of the execution will not be given to the end user. It may demotivate, but it is better to resist this mood. An artificial task must be done in good faith, as if the fate of the project depends on it.

The result of solving your first task will be the first impression about you from colleagues who were not at the interview.

Another version of the task for mastering the toolkit is “run the project on the local machine / test environment”. Sometimes this process is described in the instructions. But they are usually old and sometimes irrelevant. You can bring real benefits to the project if you write a new instruction with clarifications on the problems that have arisen. Surely in the university I had to write an RGR to report on some disciplines. It's almost the same here. The document should reflect the actions that must be performed to run.

Typically, the steps to launch the product on a test environment are approximately the following:

• clone a repository, switch to some branch or tag
• make out some configuration file
• prepare database structure
• fill it with test data
• Build or compile a project
• run a set of console scripts in a specific sequence

In the process of starting the system, unanticipated problems will inevitably occur locally locally.

Found solutions to the problems need to be added to the deployment instructions. Then the next time you follow the instructions, these problems will no longer arise. When filling out configuration files and calling scripts, you need to pay attention to what value is used where, and with what it should coincide. For example, if a project is built using the CI system and then launched by a script, it is important to understand where to write the branch name or commit number. It so happens that the script involves the transfer of an IP address or DNS name of the database, its username and password. In this case, you need to know which address to use for the test environment, which logins are there and what passwords you need to specify for them.

Some tasks may seem simple for experienced developers and cause trainees' difficulties. This is a normal occurrence.

Developers have to solve technical problems every day. Experienced employees have already solved many problems before, and newcomers have yet to deal with them. The best tactic will be to write down all the errors encountered in the document "Solving problems with $ {task name}". For each problem, you need to formulate a hypothesis about the cause, find solutions on the Internet and try them in turn. The result of each attempt also needs to be recorded.

Making your research in the form of a document will allow:

• unload small parts from your head. For example, configuration parameters, DNS / IP addresses, console commands, and SQL queries.
• remember "what did I do yesterday" when the task is stretched for several days
• Do not wander around. You can always read what you did before and understand that you are back to the original problem.
• clearly answer the question: “what did you do today?” even if there is no ready-made solution yet.

You need to be able to tell the status of your tasks to colleagues

From time to time, colleagues will be interested in your successes and share yours. A little time is allotted for this daily or weekly.

If you do not track the problems encountered and resolved, then the description of your successes will look like: “I tried to do the task, but I can’t. I’m looking for a solution so far. ” From such a story it is not clear whether the trainee did anything or just sat a habr reading. Does he need help? Has the situation changed since yesterday?

If you keep a document with a search for solutions, you can say, “I'm trying to do this task. I had such errors. So I decided like this. I have not managed this yet. There are such hypotheses and solutions. Now I’m checking them. ”

If the task can be measured at least somehow, then the numbers should sound in the status. For example, for the task “to write unit tests for a module”, we can say “I plan to do 20 tests, now I wrote 10”.

The more details you provide, the better your colleagues will understand what you were doing. This will form a positive attitude towards colleagues and allow them to understand whether you need help or not.

Feel free to ask for help.

I wrote above that when a problem arises, you need to formulate a hypothesis about its causes and solutions. However, it happens that hypotheses are not justified, and independently found solutions to the problem do not work. In this case, it is better to ask for help. In order not to abuse the attention of colleagues, you need to sit on each problem yourself. If in a couple of hours it was not possible to find a solution, it is time to seek advice from more experienced comrades.

It is best to start with the question: “has anyone encountered a problem before?” With a brief description of the problem. It is advisable to attach a piece of error message or a screenshot. This is the first time it’s better to send it to some general chat for work. So you do not interrupt the work of those who are really busy. At the same time, free colleagues will see your message and will be able to help.

If no one helped after a message in the general chat, try to catch an experienced colleague during the break: lunch, tea / coffee, a game of tennis or a smoke break. If this did not work, then report your difficulties on the fly or stand-up.

When solving known problems, this may end. If the problem is new, then an investigation will begin, where it will be necessary to act according to the circumstances.

The “important” tasks for beginners that the end user needs will be boring and small. For example, “add an additional column to the report” or “correct a typo in printed form” or “implement a model method for loading client attributes from a DBMS”. The goal of such tasks is for the beginner to become familiar with the subject area and integrate into the daily work.

It is important not only to technically solve the problem, but also to expand knowledge of the subject area.

In the description of the task, in chats and conversations, terms will be found. They may look like long familiar nouns. However, within the framework of the information system, they have a special, more precise meaning. The meaning of the detected terms is best written in a special document - a glossary of terms. When adding to the dictionary, it’s enough to write your understanding of the word, and for a real transcript it is better to contact the analyst. If he is absent, then to the old-timers of the project. Maintaining a glossary of terms is one of the simplest ways to familiarize yourself with the subject area of ​​the project.

As soon as you find a common language with your colleagues, they will begin to see in you not a novice trainee, but an equal specialist.

There are special tasks, for example, "write unit tests for a module." It can hardly be stuck for a long time with a search for solutions. Moreover, she is serious enough and is given not only for training the trainee. The written tests increase the stability of the project by reducing bugs in the application and reducing the time for testing by people. In an ideal world, unit tests are written immediately during development, but the reality is different as always. It happens that the developer of the module completely holds it in his head and does not see the need to write them. “Everything is obvious, what is there to test?” Sometimes modules are written in emergency mode and there is no time left for unit tests. So in the real world, unit tests may not be. Therefore, the task of writing unit tests is entrusted to a beginner. So the trainee will be able to quickly get used to the project,

It happens that interns and beginners are assigned the role of full-fledged testers. Usually, before this you need to deploy the product locally and read the requirements. As a result of the new employee is expected:

• questions like “if you do like this, then it will turn out like this. This is not required in the requirements. It should be?"
• tasks in the bug tracker "in the requirements it is written like this, but in fact it’s different."

Testing is an overly broad area of ​​activity for this article. If you were given a similar task, search the Internet for the best way to accomplish it.

Nakosyachite - get fired

In a normal organization, if it suddenly happens that an inexperienced employee gains access to something critical and ruins something, then the one who committed this will be to blame. Because the newbie by default does not have access to critical infrastructure. With adequate guidance, all dogs will not be let down by an inexperienced trainee.

If something happens suddenly, they will not be fired due to one incident. People learn from mistakes. The running trainee received a valuable lesson and this is very different from other trainees. If you dismiss the slammer, then another will come in his place and mow in the same way.

The main thing is to learn from mistakes and not repeat them again.

If a person does not draw conclusions from his mistakes, then they will try to say goodbye to him. However, the world is diverse. In some gangster organization they can immediately throw out the window for the first mistake. But it’s better to avoid such companies, for which you should first inquire or find out more during the interview.

Incidents are best avoided

Even if you are not personally fired for the jamb, such an incident will cause undesirable problems for your team and the project as a whole. Therefore, be especially careful with the operations of deleting or creating tables in the database, files, service instances and documents in the project knowledge base. If you meet the address of the new connection, check with at least two different people what you can do there. Check your rights on environments not by trial and error, but by appropriate commands. For example, the right to delete files using the `ls` command, the right to work with tables in mysql using the` SHOW GRANTS FOR 'user' @ 'host'; `command, and the like. In almost any instrument you will have a similar opportunity.

When editing files, just in case, keep yourself a copy of the original.

Several barriers are built between the intern and the end user.

If you could immediately give your product to the consumer, you would not be able to get a job, but embark on a "free swim". But while you do not have such an opportunity (and at the same time responsibility), you need to go through several stages of control on the project.
The first one is a mentor check. He evaluates the beginner's solution from a technical point of view. If a mentor has not been appointed, then you need to find him. To do this, you need to choose someone from the project’s old-timers and at the break ask him to see the solution: is the problem solved correctly? If you start to look and answer, then a mentor is found. If you ignore it, then you should ask someone else.

The next stage is Quality Assurance. In Russian - testers. In Soviet - standard control and quality control. They must make sure that the result of the intern's work corresponds to the task assigned to him. They will rarely be read into the code. Most often, testers will check the assembled project, which the developer saves in the version control system.

The third stage is the release manager. There may not be an individual person for this task, but someone still plays the role. He checks that testers have confirmed that the project can be released. After that, he performs the actions of delivering the product to end users.
In small organizations, these barriers may be absent for various reasons. However, they will not set the task for the beginner to change something important. Because nobody needs this risk.

You must first get involved in the battle, and there it will be seen.
Napoleon Bonaparte

I hope the article helps you overcome your insecurity and submit your first resume. Of course, you must first prepare. But do not overly tighten. You most likely already studied for several years at a university or college. Where to pull further? In the end, it’s better to hear “no” once from a specialist and work on the mistakes, than to say “no” to yourself every day and stop in professional growth.

After employment, you need to concentrate on growing from an intern to a full member of the team. Such growth is usually accompanied by an increase in your pay.

I wish you patience and perseverance.