Hot footprints on a thorny path

The post is addressed primarily to those who are just going to pass an algorithmic interview or were unsuccessful. For the rest, I apologize for the probably inappropriate instructive and instructive tone.

Where I am?

In the past two weeks, I successfully passed the code writing section in Yandex, I’m waiting for the finals. This is already my fifth attempt to get into the company, and the third after taking the Yandex.Practicum course on algorithms, which I completed at the end of the 21st year, i.e. a little over a year ago. The tasks this time, according to my subjective feeling, turned out to be a little more difficult than I expected and than came across in previous attempts. The first task was close to medium, and the second was somewhere between medium and hard. Topics: arrays, strings and, of course, hash tables adored by Yandex. Another problem with a matrix came across.

Algorithms at the Practicum

I studied well during the workshop course – I solved everything in three months, coped with many complex tasks on my own, was active in chats and gave tips to others. Overall, I give the course a good rating. The developers of the course managed to fit quite a lot in such a short time and, what is important, not just cram it somehow, but also understand it quite well in most cases. Apparently, the course on algorithms is one of the best Yandex courses, if not the best.

In order not to look affiliated, I will note that there were also disadvantages. During my passage (it is also worth noting that since the 21st year the course has changed somewhat), some additional complex topics were not analyzed in sufficient detail or explained incomprehensibly (for me), there were not enough illustrations, which, however, were always supplied with basic topics. A couple of times I turned to alternative sources and there the explanations ‘came’ to me better. A couple of times I came across problems that I could not solve, and when the mentor suggested a solution, I fell into a stupor: ‘How could I even hypothetically think of this, based on the theory provided?’

The advertisement for the course claims that it is enough to spend an hour a day. You can agree with this conditionally. Most days, yes, give or take, as long as everything goes smoothly. But when you come across a more difficult task, you may have to strain. Several times I had to rack my brains for many hours and do many ‘sets’ throughout the day. You can, of course, skip it as a last resort, but a lot of difficult tasks are required. You can ask for a hint, but the mentor does not always answer right away – sometimes he waited half a day, or even more. Sometimes he thought of it himself, without waiting.

Push-ups after a good study on a good course

And at this moment a logical question may arise – how then, after such a ‘good’ course, I ‘pushed up’ for another year and even more? The short answer is that the course is not interview preparation.

Now for the extended answer.

It is necessary to know the algorithms and, in particular, the course is useful and recommended, but, as it turned out, it is not enough.

Not the first and not the first time I will note that passing an algorithmic interview is a separate and special skill that requires training, one might even say, cramming (‘squats’ / ‘push-ups’, etc.) You should practice solving simple tasks for a while and no debugging, no running, no use of debug output on leetcode. The solution must pass from the first, from the very first time!

This process is most likely different from how you used to program before. In common practice, some of your errors are found by the development environment, some of the errors get out on their own during startup and debugging. Once again, straining the brain is more difficult and unusual than clicking on the green triangle 10 times.

After you have written all the code, read and reread it carefully line by line. Do this even if you are 100% sure that everything is correct.

Common mistake: forgot to declare a variable. Accordingly, for each variable, check that you have not forgotten to declare it. Another mistake: declared but forgot to use it — make sure every declared variable changes somewhere. If there are several functions in the solution – check that the list of parameters when calling and declaring the function is the same – both in number and order, and in all calls.

Practice doing dry tests. In some cases, they are easier to do, in others more difficult, and in some even too difficult.

Well, if you did everything that is written, checked / double-checked, launched it and still got an error, then don’t swear as loudly as I do. And know that you are not alone. Also, take your time to look at the debug output and find out in which line the error occurred. Instead, take a closer look at the inputs where the solution ‘failed’. Perhaps you will quickly understand what is wrong, and if not, then once again do a dry test specifically with this data. I used to spend a lot of energy on a trifling mistake and now I no longer think that it was in vain.

There are quite a few videos on the Internet of how people go through test interviews with writing code. Mostly in English, but also in Russian. Recommended for viewing. Not that it is very exciting, but instructive. Watch where and how people mess up, how they test their code, how they find or don’t find bugs.

Also make allowance for the fact that you will be stressed and ‘blunted’ during the interview.

Another course?

I will mention the free course “Preparing for an algorithmic interview” from the Practicum. It has a fairly high entry threshold and is hardly worth considering as a ‘complete’ tool for preparation. But, in my opinion, it is great as an aid. It makes sense to take it after the main course on algorithms. And you can, as an option, using its materials to develop your own free or partially free track. The course allows you to see well where you have gaps, but you can fill in the address using other, possibly different resources, for example, the same Stepik. It happens that one topic is better dealt with in one place, and another in another, which I already wrote about at the beginning.

The features of passing the interview with the code were analyzed, and here this post largely repeats what was stated there.

I even dare to think that he did not appear without my indirect participation. After successfully completing the course on algorithms and not successfully passing the interview, I wrote a rather lengthy letter as a final feedback to the curator of the main course, and shortly after that, an additional course on interviews appeared.

cat on paper

In conclusion, I want to talk about the “paper interview”. I originally wrote this post in the TG group and had no intention of posting elsewhere. However, it elicited a rather lively and mostly positive reaction. Once again, there were those who spoke somewhat disparagingly about the ‘paper interview’. That, they say, no one really explained what sacred meaning is in such an interview. In response, someone again followed up with the well-known objection that such interviews are conducted in Google and Meta.

It’s unwise to get involved in holy wars, but I won’t refrain from throwing in my 5 cents.

Programming with a ballpoint pen trains the skill of writing clean code the first time. If the code is 5-10 lines, then it can be easy to identify errors. What if there are many thousands of lines? What can be the cost of an error in the code? What can be the labor costs for its identification? It is clear that there are all sorts of advanced technologies and testing methodologies, but the error can be intricate.

I will add to this that I myself went through the same algorithmic interviews with “Yandex-notebook” also in Diasoft and in a small company UBIC. That is, not only IT giants are now already practicing this.