For beginner programmers

After graduating from university, after several years of working in my specialty, I had the idea to come to the programming department and offer to organize a lecture for senior students, where I would tell them how to work as a programmer in general, and what I myself would like to know about it when I was studying. This did not happen for various reasons, but the idea remained, and I decided to implement it in the form of an article. The text is written for students without work experience.

A little bit about yourself. I am a web developer, I have 12 years of experience, my main language is PHP. The projects where I work are usually large systems that a team of programmers is working on, and which some business needs for its activities. Such projects are called “enterprise”. For example, these are online stores and the internal systems associated with them.

Programming languages

Let's start with programming languages. We studied C++ in our first years at university. You need to know the following about him. If you have figured out classes, pointers, and write all your labs in C++, this does not mean that you know C++. There are many technical nuances there – undefined behavior, smart pointers, virtual destructors, and much more. You also need to know the main libraries – std, boost. If you don’t know this, you won’t be hired for real jobs. If only for an internship, which is not available everywhere. Even professional C++ programmers sometimes complain about the technical complexity of C++.

More modern low-level languages ​​are Rust and Go. There are higher-level languages ​​- for example Java, C#, PHP, Python. All of them are very common, there is no need to know C++ well. But in general, understanding how things work at a low level is a plus.

Lisp and Prolog languages ​​are not used in their pure form. Functional languages ​​that are used in practice are, for example, Haskell, Scala, Erlang, F#. But their share relative to imperative languages ​​is not very large. You need to know that there is such a concept of immutable variables, it has its advantages, and programs can also be written in such languages.

I can recommend learning HTML, CSS and JavaScript, even if it is not required by the program. The browser has good capabilities for displaying graphics; it is convenient to do laboratory work in it, where a user interface is needed, but no specific programming language is required.

Web programming is very common now, usually in such projects there is a database and a server-side language that generates HTML for the browser, or returns the necessary data to the browser, and the interface is created using a JavaScript application. The server-side language can be anything, often it is one of the ones I wrote above. JavaScript is also used as a server-side language.

For any languages, it is important to know not only the language itself, but also the common libraries and frameworks for it. They won't hire you if you don't know at least one framework.

Database

Databases are widely used. There are quite a few projects where there is no need to store data, and if they do need to be stored, then databases are usually used for this, and not just files. You need to know SQL and be able to work with them. There is no need to know relational theory; no one asks about normal forms. You need to know how to divide data into tables and how to join them through foreign keys. In practice, INNER JOIN and LEFT JOIN are most often used; other forms are not recommended, as they are difficult to understand. In joins, it is better to write only the key equality condition; it is better to write additional conditions in WHERE.

In the context of database theory, there is a common statement that it is not recommended to use artificial (surrogate) auto-incrementing primary keys; it is better to find unique natural keys. This is wrong. In reality, any 2 objects can have the same characteristics. Characteristics that can be used as a primary key are the same artificial keys, simply invented for non-computer accounting. Usually they are also incremental in nature, for example, inventory numbers or telephone numbers. In this case, there is no need to use the phone number as the primary key for a table with a list of people; a person can have 2 numbers or none. Phone number can only be the primary key for the phone table.

Artificial keys that already exist in the domain are usually not optimal for performance, so make a numeric auto-incrementing primary key, and add a unique index on a field that can be considered unique. The primary key is needed for the system itself so that it is possible to programmatically identify and distinguish the corresponding objects, so you need to do it in a way that is convenient from the technical side.

The case where you do not need to use a separate auto-incrementing key is intermediate tables for many-to-many relationships. A relationship involves 2 objects that it connects, so the primary key for it consists of the keys of these objects. For other relationships, an intermediate table is usually not created, so for them the primary key of the main table is used.

Version control systems

Version control systems are also widely used. The main ones are Git, Mercurial, SVN. The most common system is Git. They are needed to store change history, track and manage changes, especially when working in a team.

If you are not familiar with them, and have tried to develop some kind of large program, then you most likely had the need to make copies of the current state, which definitely works, and which you can return to if new changes do not work. As a result, you had folders like “ProjectName v1”, “ProjectName v2”, “ProjectName v3”. A version control system simplifies these actions and has more advanced capabilities, including for many people working on one project. You need to know what a commit, branch, merge request are, and how to work with them.

Related disciplines

You don't need to know physics. It is advisable to have a school-level understanding of basic terms, mainly related to electricity, in order to understand what is being discussed, if it is discussed somewhere.

You don't need to know mathematics in detail. But studying it shows how well you can make sense of unfamiliar information. You also need to have an idea of ​​the basic concepts, in case you need them somewhere – percentages, sine-cosine, logarithms, matrices.

Separately, it is necessary to note the mathematics associated with the complexity of the algorithms. You need to have an idea of ​​what the complexity of algorithms is and how it is assessed. Usually this is not required in work, but sometimes it is still required. Despite this, it is often asked about it during interviews, as this is one of the ways to test at least some knowledge in the field of IT in a few minutes. Sorting, trees, graphs. A regular loop is linear complexity, a nested loop is quadratic, tree or recursion is usually logarithmic, but depends on the situation. The best and worst case may have different complexity. The constant multiplier does not count.

In work, what is more important is not knowledge of something, but the ability to study unfamiliar material. But to study, you need to at least know something.

Job Search Process

Those who have not yet looked for a job often have misconceptions about the process.
It seems to happen like this. You read the advertisement “Programmer Wanted”, you come and ask, “Are you still looking for a programmer?” – Yes – I agree – Do you know this and that? – Yes, it’s like this and that – Do you know this? – No, but I’ll figure it out. – Okay, you’re accepted, start working.” This doesn't happen.

This is what usually happens. The company conducts interviews for a couple of weeks, then selects the best candidate. Even if you answered all the questions, it is far from a fact that you will be hired. If another person has 6 months more work experience, or has some additional courses, projects, speeches, or answered in more detail and confidently, they will hire him and not you, even if he was interviewed later. So, it is extremely rare for them to take the first suitable one.

If you don't know something, no one will check whether you figure it out or not. The company won't pay you money to test it. A specialist with good experience can be trusted, but no one will believe you without experience. That’s why you need to know at least one common framework for your language, so your chances of getting a job where it is used are higher.

Sometimes they don’t take any of the first candidates and continue to look for a month, two, or longer. Because it’s not so easy to fire a bad specialist; it’s easier to wait and hire a normal one.

There may be one or several interviews. Usually, first a conversation with HR, then a technical interview with a programmer, most often with a team leader (team lead). In small companies there may be one technical one at once, in large companies there may be 3-4.

HR specialists are not always competent. Technicians who conduct interviews can sometimes be unpleasant people, try to show superiority, ask too difficult questions, and ask questions that are not what is needed in the real job. We must understand that this happens. You usually won’t encounter HR specialists after being hired, but if you do encounter such a technical specialist, then you need to think about whether you really want to work in such a company.

Create an account on GitHub or Bitbucket, write a couple of small projects with well-designed code and post it there, add a link to your resume. Test tasks are also usually asked to be posted on GitHub.

While you have no experience, take any test tasks. This will give you an idea of ​​what kind of tasks there are in general. A normal test task can be completed in one evening. Test tasks for a week are strange, it is better to avoid such companies. You can do such a task out of interest, but not send the result. Sometimes they give you a small task and allow you to send it within a week, this is normal.

In a test task, it is important not only that it should work, but also the style of the code, the class structure, and how clear the code is and how easy it is to read. There is no need to comment on each line; on the contrary, this is a minus. It is necessary to align indentations, clearly name variables, classes and methods, break large code into different methods, and move groups of related methods into different classes. Generally accepted approaches should be used, even if they seem redundant for a small task. There is a difficulty here that if there is no experience, then it is not clear which approaches are generally accepted. There is nothing you can do here; you need at least indirect experience. Check with the examiner what was wrong with the test task, read technical books and articles, study the code of open-source projects, try to write something yourself.

Often during interviews they ask if you have any questions. They say that not asking anything is a negative, as if it shows that you are not interested. This is, of course, not true; as long as you don’t have experience, you would be able to find at least some work, but not all HR specialists understand this. I usually ask how many people work in the team, and anything else depending on the situation.

If you already have a little experience here and there, it's tempting to add everything to your resume. Frequent job changes in HR raise suspicion. This may indicate that you interact poorly with the team and cannot stay in one place. 2 years or more in one place is considered normal, 1 more or less, less than 1 is already strange. While you have little experience, explain in the description of each place why you left – maybe it was a small one-time project and you completed it, or the salary was paid less than promised. Consider combining several places into one with a name like “One-Time Projects” or “Freelancing”, without unnecessary details.

It is not recommended to speak badly about former colleagues, especially when talking to HR. If you had problems with supporting bad code at your previous job, look for neutral language, or simply don’t provide details. In a conversation with a programmer, you can carefully discuss the technical shortcomings of solutions; at least he will understand. But it’s also better not to do it without a special reason. There is no ideal code, there are some shortcomings everywhere, the only question is how acceptable their number is.

Work process

Once hired, you will be working as part of a team, so the ability to interact with people is very important. This is called soft skills. They are tested during interviews. You need to be able to communicate politely, defend your point of view without being rude, even if someone is rude to you, you need to be able to listen and not interrupt, let the other person express his thoughts, you need to be able to make compromises, accept another point of view, and do something , with which you personally do not agree.

Almost every job has a code review process. You have done your task, written the code, create a merge request with changes, and one of the other programmers reviews it. For this purpose, version control systems and related tools are used. The code should not only work, but also be understandable to others. Because then the task of changing this code may go to another programmer, and it’s better for the company if he doesn’t waste time figuring out what you wrote there. During a code review, compliance with the generally accepted style, structure and clarity of the code are checked, and the code is analyzed for possible errors.

You can also note the testing process. Unit tests are often done for code; they are located along with the main code of the project, they are written by programmers. The test sets the correct inputs and outputs for some code, this ensures that if later changes to that code make an error that causes the output to change, it will be noticeable. Such tests are run before each new change is uploaded to the production server (“in production”), as well as immediately when a merge request is created.

In addition to these tests, there is a testing department. Testers test the operation of the project from the user's point of view; they check the main scenarios manually or using special automated tests that control the browser or application window and simulate user interaction with interface elements. Sometimes such tests are also written by programmers.

Tasks are assigned in the task tracker, there are many different ones, the most popular is Jira. An issue has a number, which usually needs to be specified in the commit message. This way, other programmers will be able to find out in the future why a change was made in the code. There is often a requirement to include in a task the approximate time spent on it. This is necessary for reporting and planning, in normal companies no one will ask you for evidence of why you spent 2 hours instead of 1. Some companies require you to install controls that take screenshots to verify that you actually worked, these are better if possible avoid. Clarify this during interviews.

An often used approach is that the workday begins with a general call via the Internet or a meeting in the office, where everyone talks about what they are doing, what progress is on tasks, and whether there are any problems or questions.

Remote work is practically no different from office work, only you don’t have to go to the office. There is usually a work chat where you can discuss any questions.

Books

I can recommend 3 books that are worth reading:
McConnell – Perfect Code
Gamma, Helm, Johnson, Vlissides – Object-oriented design techniques. Design Patterns
Evans – Domain-Driven Design (DDD): structuring complex software systems