Get rid of the fear of the first job

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

The problem with this world is that well-mannered people are full of doubts and idiots are full of confidence.

Charles Bukowski

I recently did another one-on-one programming session. Unlike regular classes, the topic was not the construction of the language and not the problem in solving the problem. The student shared his concern about future employment. The student himself was quite smart. One of those who come to the courses goes through the entire program faster than anyone else and with original solutions, but all the time 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 like this:

• Every year, a lot of students graduate from universities and they all go looking for work. That's a lot of people. Surely they will take the best, but I will not get a place.
• What if I screw up and get fired right away?
• What if in the course of work they realize that I'm stupid and kick me out?

This student was not the first person to whom I answered such questions. They occur to many, and usually you have to tell without preparation. This time I decided to record my monologue in a notebook. I thought it would be a couple of paragraphs, but I got a whole 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 by a developer for developers. However, if you plan to do testing, administration, or anything else in IT, then some of the tips will also come in handy.

Not hired 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 asking some university student you know: how do people in his group get admission to exams in disciplines like "database" or "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 copy from them, cramming answers to questions and handing over.

That's how it was when I was studying on my own. However, my experience may not be representative. So 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 reasoning about the reasons beyond the scope of this article. I won’t have enough for a full-fledged study, so I will draw a conclusion from the available facts.

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

Few graduates can really compete with a capable, well-prepared student. However, even if you studied in good faith, then after the first interview you most likely will not be hired. After the second, probably, too. Everything can turn out well, but it is better to tune in not to the assault, but to the siege. An unsuccessful attempt to get a job is just an excuse to work on the mistakes and try again. I will not talk about preparing for interviews. Much has already been written on the Internet on this subject. I will only say that there are nuances in passing interviews, for the explanation of which in the program of your training, time is hardly allocated. 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 keep interviewing from turning into madness, you need to get better after each new attempt. Memorize or write down the questions you were asked during the interview. Upon returning home, look through this list and check yourself using the Internet. So you will understand where you made a mistake, where is the interviewer. This also happens. Review or study topics where you answered poorly and try again.

In addition, there is a pronounced seasonality of the labor market. Smart companies plan hiring based on graduation dates. In the spring, there are more vacancies for beginners than at other times. However, the competition at this time is higher.

Stupid - get fired

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

From a newcomer to work, they expect:

• General technical knowledge
• Studying the features of the subject area of ​​the company
• Mastering the tools and practices used

Some organizations organize training courses for newcomers on the technologies used, tools, and local practices. For example, good manners when using corporate mail, the procedure for changing documents in a wiki, local features of working with VCS and a bug tracker.

There are also technical introductory courses, but their usefulness is questionable. If it comes to employment, then employers are convinced that you have some kind of sufficient level of knowledge. It is best to simply take such courses in good faith, as a small formality. They might actually be of some use.

When you get to work, remember that a newbie will definitely not be assigned an urgent, complex, and at the same time important task. Most likely there will be only one of these properties. Or simple, but urgent: fix 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 rakes. Or important, but experimental. For example, a project that everyone has wanted for a long time, but cannot allocate time for implementation.

The tasks of mastering the toolkit 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 terms from the subject area are used as in the entire project. In this case, the result of the execution will not be given to the end user. This can be demotivating, but this mood is best resisted. An artificial task must be done conscientiously, as if the fate of the project depends on it.

The result of solving your first task will form the first impression of you among colleagues who were not at the interview.

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

Typically, the steps to run a product on a test environment are something like this:

• clone a repository, switch to some branch or tag
• create some config file
• prepare the database structure
• fill it with test data
• build or compile the project,
• run a set of console scripts in a specific sequence

In the process of starting the system locally, unforeseen problems will inevitably arise.

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

Some tasks may seem easy for experienced developers and may be difficult for interns. This is normal.

Developers have to solve technical problems every day. Experienced employees have already solved many problems before, and newcomers have yet to cope with them. The best tactic is 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 one by one. The result of each attempt must also be recorded.

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

• get the little details out of your head. For example, configuration settings, DNS/IP addresses, console commands, and SQL queries.
• remember “what did I do yesterday” when the task stretches for several days
• don't wander in circles. 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 solution yet.

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

From time to time, colleagues will be interested in your progress and share theirs. A little time is allocated for this daily or weekly.

If you don't keep track of the problems you encounter and solve, then your description of your success will look like: “I tried to do a task, but it doesn't work. For now, I'm looking for a solution." From such a story it is not clear whether the intern was doing something or just sitting and reading Habr. Does he need help? Has the situation changed since yesterday?

If you keep a document with the search for solutions, then you can say “I'm trying to do this task. I had such errors. I decided like this. Haven't dealt with this one yet. There are such hypotheses and solutions. I'm checking them now."

If the task can somehow be measured, then numbers should sound in the status. For example, for the task “write unit tests for a module”, you 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 you among colleagues and will allow them to understand whether you need help or not.

Feel free to ask for help

I wrote above that when a problem appears, you need to formulate a hypothesis about its causes and solutions. However, it happens that the 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 a solution was not found in a couple of hours, it's time to seek advice from more experienced comrades.

The best place to start is with the question: “Has anyone else had this problem before?” with a brief description of the problem. It is advisable to attach a piece of the error message or a screenshot. It is better to send this message for the first time to some general chat at work. So you do not tear off those who are really busy from work. At the same time, free colleagues will see your message and be able to help.

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

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

The “important” newbie tasks that the end user needs will be boring and small. For example, "add an extra column to the report" or "correct a typo in the printed form" or "implement a model method to load customer attributes from the DBMS." The purpose of such tasks is for the beginner to become familiar with the subject area and integrate into 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, there will be terms. They may look like 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 recorded in a special document - a glossary of terms. When adding to the dictionary, it is enough to write your understanding of the word, and for a real transcript, it is better to contact the analyst. If it is absent, then to the old-timers of the project. Maintaining a glossary of terms is one of the simplest ways to get involved in the subject area of ​​a project.

As soon as you get along with your colleagues, they will begin to see you not as a novice trainee, but as an equal specialist.

There are specific tasks, like "write unit tests for a module". You can hardly get stuck on it for a long time with the search for solutions. At the same time, it is quite serious and is given not only for training an intern. Written tests increase the stability of the project by reducing bugs in the application and reducing the time for human testing. In an ideal world, unit tests are written immediately during development, but the reality is, as always, different. It happens that the developer of the module completely keeps 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 exist. 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, and the project will be able to save the time of more highly paid specialists.

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

• Questions like “If you do this, then it will work like this. It's not in the requirements. It should be?"
• tasks in the bug tracker "in the requirements it is written like this, but in fact it is different."

Testing is an overly broad field for this article. If you are given a similar task, search the Internet for the best way to do it.

You screw up - you get fired

In a normal organization, if it suddenly happens that an inexperienced employee gets access to something critical and spoils something, then the one who allowed this will be to blame. Because by default, a beginner does not have access to critical infrastructure. With adequate guidance, they will not release all the dogs on an inexperienced trainee.

If suddenly something happens, then they will not be fired because of one incident. People learn from mistakes. The messed up trainee learned a valuable lesson and is very different from other trainees. If you fire the one who screwed up, then another will come in his place and screw up 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 different. In some gangster organization, they can immediately be thrown out of the window for the first mistake. But it is better to avoid such companies, for which you should first make inquiries or find out more during the interview.

Incidents should be avoided

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

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

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

If you could immediately give your product to the consumer, you could not get a job, but set off on a "free float". 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 newcomer'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 one of the old-timers of the project and ask him to look at the solution during the break: is the problem solved correctly? If he starts looking and responding, then a mentor has been found. If he ignores it, then you should ask someone else.

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

The third stage is the release manager. There may not be a separate person for this task, but someone still plays the role. It checks that the testers have confirmed that the project can be released. After that, it performs the steps to deliver the product to the end users.
In small organizations, these barriers may not exist for various reasons. However, they will not set the newcomer the task of changing something important. Because no one needs this risk.

You must first get involved in the battle, and then we'll see.
Napoleon Bonaparte

I hope this article will help you overcome your insecurities and send your first resume. Of course, you must first prepare. But don't over-tighten. You have most likely been in high school or college for several years already. Where to pull further? In the end, it is better to hear “no” from a specialist once and work on the mistakes than to say “no” to yourself every day and stop in professional growth.

After employment, you need to focus on growing from an intern into a full-fledged team member. This growth is usually accompanied by an increase in your pay.

I wish you patience and perseverance.

Only registered users can participate in the survey. Sign in, you are welcome.

What were your first tasks at your first job in IT?

• Complicated

• Important

• Urgent

• None of the above

75 users voted. 20 users abstained.

What did you have to do in your first job?

• Install the product locally

• Test an existing product

• Perform a training, fake task

• Engage in an experimental, real project for a client

63 users voted. 25 users abstained.

How many students in your group during the training could independently complete tasks in technical subjects?

• 1 of 10

• 1 of 5

• Every second

• All, with rare exceptions

70 users voted. 19 users abstained.

Source: habr.com