When does a developer learn to solve algorithmic tasks? Most often, this happens either at the very beginning of the journey, or when preparing for an interview. At the beginning of the journey, the task of choosing the optimal data structure, developing and evaluating the complexity of the algorithm helps to change mental habits – to go from expressing thoughts in natural language with a lot of inaccuracies to an unambiguous statement in a programming language. The algorithmic task allows not to overload the developer with the details of some subject area and to focus on data processing. An ideal exerciser for thinking without being tied to business concepts with their inaccuracies and contradictions.

There are two popular positions when it comes to preparing for interviews. Some say that after an interview, algorithms are almost never used for years, and a person who easily solves algorithmic problems is no better than others in solving business problems.

Others believe that algorithms are a base without which a developer does not have the skills to solve complex problems. And the algorithm section for hiring is considered an ideal test of all the key skills of a programmer.

In this article, I want to share my point of view on why it is worth or not worth pumping knowledge of algorithms. I will try to take a balanced look at the algorithmic problem as a way to test the skills needed in practical work.

I will analyze several skills. I will rate each one on a scale from 0 to 3. 0 – the task does not test the skill. 1 – rather does not check. 2 – checks faster. 3 – checks.

Collection of requirements

When solving an algorithmic task, it is important to pay attention to the details of the requirements. Often the key to the optimal solution is some kind of input data constraint or given example data.

But such verification of work with requirements is disconnected from practice. First, there is no connection to the subject area from which unclear or contradictory requirements may come. Secondly, the distribution of input data values ​​is usually not indicated, as if it were uniform. Therefore, the score is 1.

Designing

In my opinion, the key stage in solving tasks is on algorithms. Of course, there aren’t any architectural patterns here, but there is a system design section for that. In the algorithms section, it is checked how the developer goes through the possible solutions of the task, when it stops, how it takes into account the hints. It examines how typical data processing techniques are sorted and combined. An understanding of the operation of basic data structures is tested. And, of course, a comparison of different decision options regarding temporal and spatial complexity. The rating is 2. Why not 3? There are few solution options. In tasks of medium complexity, there are often 2 or 3 of them. In real tasks, you have to choose from a larger number of options.

Code organization

What is important for writing a small block of code? For example, give variables understandable names. There is no time to think of variable names in an algorithmic interview. After all, after writing the code, it still needs to be tested in a notebook, taking into account the interviewer’s comments. It is worth setting aside time for a possible fix of errors. Maybe there’s a challenge or two ahead. Never think about variable names. Moreover, in real tasks, the quality of a name is evaluated from the point of view of a) the context of the code and b) the coding standards adopted by the team. Ability to decompose function code? Not tested either, because usually the solution is a small block of code.

Ability to simplify a small block of code within a single function? Avoid unnecessary nesting that is difficult to read. Check the conditions in such an order that the code is easier to read. Apparently, this is checked through the estimation of the complexity of the algorithm. The simpler the code, the easier it is to calculate its complexity. If the algorithm is optimal, but written too complicated, that is, there is a risk of not being able to calculate the complexity of the algorithm at all. The rating is 2. Why 2 and not 1? If a person can choose a short and easy-to-understand version of the code, then with variable names and method decomposition, he will most likely cope. But this is not accurate. Therefore 3.

Understanding the code

What is a bug? This is the difference between how the developer understands the logic of the code and the logic. It is very important for a developer to be able to identify when he does not fully understand the code. How is code comprehension tested? Without understanding, it will not be possible to explain that the written algorithm always solves the task. Without a good understanding of the code, it will not be possible to assess its complexity. The rating is 3.

Testing

Compiling a quality set of test cases to test all lines of code, all edge cases, memory consumption, and performance is a separate craft. In my opinion, this is verified by a task where it is necessary to list the test scenarios on the already ready code.

Rather, the algorithm test tests the ability to operate with numbers, values ​​of variables in the mind. That is, perform the function of a debugger. Not a very practical skill. But another important point is the test of memory, concentration of attention, speed of thinking. The time at which a person tests the code written in the notebook depends on this.

The ability to compose a test case is checked, except for some of the extreme, borderline cases, which help to estimate the worst running time of the algorithm. My rating is 1.

Time planning

On the one hand, it is checked in miniature. If the task is solved at an interview, then you have to remember, in addition to solving the problem, that there is still code writing, testing, discussion, and possibly correction ahead. Maybe other tasks. Therefore, it is worth deciding when to ask for a hint or leave code refactoring aside. Otherwise, you can spend a lot of time thinking about different solutions and not demonstrate any of your skills at all.

On the other hand, how does the ability to allocate time for a tiny task in half an hour or an hour correlate with the ability to plan work for a week or two? Probably not. Plus, in real planning tasks, it is good practice to take a break after making a plan and review it again with a fresh head. The score is 0.

Solving problems in dialogue

First, of course, you need to be able to explain the written code. Why it is optimal and why it works in all cases, and not just on one example.

Secondly, if you read the condition of the task and at the same time did not remember the necessary decision-making, then you should play it safe and say the solution options and problems that you are considering. This is exactly the simulation of real work, when you are looking for a solution to a problem in a dialogue with a colleague. Sometimes it is enough to express your thoughts to another person in order to solve the puzzle. And the missing piece of the puzzle is easily found.

In addition, the algorithmic interview prompt helps you demonstrate your programming skills when the task in its original form turned out to be insurmountable. At the moment of the prompt, attention to details and the ability to switch the context of attention are tested. A person will stubbornly complete a started solution that does not come together in any way, or take a step back and look at the problem from the other side. The rating is 3.

The ability to learn

It is checked indirectly. If a person is good at solving tasks on algorithms, it means that there is an interest in details, the ability to delve into details, the ability to understand complex structures. With the same success, you can ask about an internal database device or framework in an interview. But it is difficult to standardize the selection process, since there are a lot of databases and frameworks, they evolve. Some are also getting old. And this theory of algorithms is updated slowly. Plus, new algorithms do not make old ones irrelevant. Algorithms are a universal theme that you can set up the hiring process once and repeat it for a very long time. The rating is 2. Why not 3? Because the theory of algorithms can be mastered once and then not train the ability to learn for a long time.

Results

All described skill tests for algorithmic tasks work only if a person has the necessary algorithmic training. Books on algorithms were read and the ability to see typical data structures and typical methods of their processing in tasks was trained.

If there is no such preparation, then a person may have the skills needed for work, but simply will not be able to demonstrate them at an algorithmic interview.

Probably, it can be compared with the knowledge of the language. If a specialist does not know the language, this does not devalue him as a specialist. It’s just more difficult to check professional skills.

Conclusion

Algorithms have been my weak point for a long time. Some time ago I decided to close this gap in my education. Partly because of interest in the topic. Partly because of the understanding that I might want to work for a company that tests algorithms in interviews. He thought about the practical benefits of the books he had read and the hundreds of problems he had solved. This is how this article came out.

I wish everyone that interest in the subject is always combined with an understanding of practical benefits. Thanks for reading my first article.

I invite you to my personal channel about programming.